Saturday, April 05, 2014

Pass variables between two PHP pages

1. Embed it as a hidden field in your form, or
 <input type=”hidden” name=”myVariable” value=”Your value” />
Now you can access in the page inside action with   the method GET/POST.
2. Add it your forms action URL
<form method="POST" action="Page2.php?myVariable1='xyz'.&myVariable2='abc'>
It will create a variable which will be accessible through $_GET[] array.
Example:
//Original page : t1.php
<html>
    <body>
<?php $x="Hello" ; ?> 
<a href="t2.php?v=<?php echo $x; ?>" >Hi</a>
   </body>
</html>
Next Page : t2.php
<?php
$x=$_GET['v'];
echo $x;
?>
3.Sessions/Cookie would be good choice for you.
Session:
//On page 1
$_SESSION['varname'] = $var_value;

//On page 2
$var_value = $_SESSION['varname'];
Remember to run the session_start() statement on both these pages before you try to access the $_SESSION array, and also before any output is sent to the browser.
Example: Code of page1.php
<?php                                    // page1.php
               session_start();
               echo 'Welcome to page #1';
               $_SESSION['favcolor'] = 'green';
               // Works if session cookie was accepted
               echo '<br /><a href="page2.php">page 2</a>';
?>
Code for Page2.php
<?php              // page2.php
               session_start();
               echo 'Welcome to page #2<br />';
               echo $_SESSION['favcolor']; // green
?>
Cookie:
//One page 1
$_COOKIE['varname'] = $var_value;

//On page 2
$var_value = $_COOKIE['varname'];
The big difference between sessions and cookies are that the value of the variable will be stored on the server if you're using sessions, and on the client if you're using cookies.
I can't think of any good reason to use cookies instead of sessions, except if you want data to persist between sessions, but even then it's perhaps better to store it in a DB, and retrieve it based on a username or id.
HTML / HTTP is stateless, in other words, what you did / saw on the previous page, is completely disconnected with the current page. Except if you use something like sessions, cookies or GET / POST variables. Sessions and cookies are quite easy to use, with session being by far more secure than cookies. More secure, but not completely secure.

Password Protection with .htaccess

Password Protection with .htaccess & .htpasswd

Introduction

The Apache web server ( the daemon that serves up your marvelous content ) allows a user to configure two files to facilitate this very purpose. Those files are .htaccess and .htpasswd.
.htaccess
The .htaccess file is a simple text file placed in the directory you want restricted access. The rules and configuration directives in the .htaccess file will be enforced on whatever directory it is in and all sub-directories as well.
In order to password protect content, there are a few directives we must become familiar with. One of these directives in the .htaccess file ( the AuthUserFile directive ) tells the Apache web server where to look to find the username/password pairs.
.htpasswd
The .htpasswd file is the second part of the affair. The .htpasswd file is also a simple text file. Instead of directives, the .htpasswd file contains username/password pairs. The password will be stored in encrypted form(may be Plain text, not Recommened) and the username will be in plaintext.

.htaccess In Depth

It can be created using a text editor and then uploaded using FTP or some similar mechanism.
You will want to put the .htaccess file in the directory you wish to protect. Remember that all sub-directories will be protected as well. Figure 1 represents a very simple recommended format for an .htaccess file whose sole purpose is to protect directories. Use the following as a template for your .htaccess file and review the directives below for more information and specific changes.
AuthUserFile /usr/uj/jurbanek/.htpasswd
AuthType Basic
AuthName "My Files"
Require valid-user
Figure 1 - Recommended .htaccess Format; A sample .htaccess file.
AuthUserFile Directive

The AuthUserFile directive in the .htaccess
file tells the Apache web server where the username / password pairs are 
going to be kept.  In other words, it tells Apache where the .htpasswd file is going to be located. 
AuthUserFile /home/jurbanek/.htpasswd
AuthUserFile /alpha3usr/uj/jurbanek/.htpasswd
AuthUserFile /usr/uj/jurbanek/www/.htpasswd
AuthUserFile /home/jurbanek/htdocs/files/.htpasswd
AuthUserFile /home/jurbanek/public_html/.htpasswd
Figure 2 - AuthUserFile directive examples.

This is the directive that "links" the .htaccess and .htpasswd files. After the text AuthUserFile be sure to put the FULL path to the .htpasswd file. 
 Relative paths can be used, but they can get quite complicated since they are relative to the ServerRoot. Do not use relative paths, use full paths when specifying the location of the .htpasswd file. Further discussion about the .htpasswd file and where to put it will occurr later. If you know where you are going to put the .htpasswd file, then you can adjust the path now. Below are a few examples of the AuthUserFile directive.
AuthType Directive
The AuthType directive is not one you have to worry about. Basic is the only type of authentication that is widely used. There are others, such as Digest authentication, but do not worry about them. Leave this line as it is.
AuthType Basic
Figure 3 - AuthType directive.
AuthName Directive
The AuthName directive is used to indicate the collective title of the documents that are to be protected. The name specified will usually appear in the authentication window that the client will see when they are prompted to type in their username and password. If the name you would like to use contains spaces, be sure to enclose the entire name in double-quotes. Below are a few examples AuthName.
AuthName "My Files"
AuthName Protected
AuthName "John's Secret Documents"
Figure 4 - AuthName directive examples.
Require Directive
The Require directive tells Apache which users/groups are able to access the content being protected. There are a few special keywords that can be used. One of the keywords is valid-user. This keyword tells Apache to grant access to anyone specified in the AuthUserFile directive, (the .htpasswd file). If you wish to specify a few users in the .htpasswd you can omit the valid-user and enter their username as specified in the .htpasswd file. See a list of examples below.
# This is a comment, it is ignored by Apache due to the # character
Require valid-user
Require john
Require dave jane

# The following line does not make semantic sense, do not do this
Require valid-user dave
Figure 5 - Require directive examples.

.htpasswd In Depth

Like mentioned earlier, the .htpasswd is a simple text file, however it should very rarely be editted by hand. There is a special program on a *nix machine that is designed to manipulate the .htpasswd file on your behalf. The name of this program is htpasswd. There are 2 fundamental ways to use htpasswd. The first way is to create a new .htpasswd file and add a username/password pair to the file. The second way is to add a username/password pair to an existing .htpasswd file.
To create a new .htpasswd file in /usr/uj/jurbanek/ with username john, the following command would be used.
# '-c' stands for 'create'.  Only to be used when creating a new .htpasswd file.
# You will be prompted for the password you would like to use after entering the command below.

htpasswd -c /usr/uj/jurbanek/.htpasswd john
Figure 6 - htpasswd command example. Note the '-c' is only used when creating a new .htpasswd file.
To add dave to an existing .htpasswd file located in /usr/uj/jurbanek/ the following command will be used.
# Notice there is no '-c' since the file exists already, we just want to add 'dave'
# You will be prompted for the password you would like to use after entering the command below.

htpasswd /usr/uj/jurbanek/.htpasswd dave
Figure 7 - htpasswd command example, adding a user to a .htpasswd file.

Sample .htpasswd File

Below is a sample .htpasswd file that contains users john and dave
john:n5MfEoHOIQkKg
dave:9fluR/1n73p4c
Figure 8 - Sample .htpasswd file.

Notes on .htpasswd files.

  • Format: username:encrypted_password
  • The username is case-sensitive. John and john are two different username's.
  • Location: It is a good idea to put the .htpasswd file outside of your web accessible documents. Try to keep it out of your htdocs, www, and public_html folders. This is a security measure. Most web servers are configured to not allow people to remotely view your .htpasswd file, but it never hurts to keep it out of the web tree.

Troubleshooting

  • to have a server configuration that permits putting authentication directives in these files. This is done with the AllowOverride directive, which specifies which directives, if any, may be put in per-directory configuration files. Add AllowOverride AuthConfig in per-directory configuration files i,e.  in <Directory ...> </Directory> directive.
  • Make sure that the path specified in AuthUserFile is the correct full path. This is a major cause of problems. If Apache cannot find the .htpasswd file, then all attempts will fail.
  • Make sure the permissions on the .htaccess and .htpasswd files are set so that Apache can read them.
    • chmod 0644 .htaccess
    • chmod 0644 .htpasswd
  • Other issues may be out of your control. Web administrators can lock down Apache so that it ignores all .htaccess files it encounters. This can be achieved with an AllowOverride None directive and option on the ServerRoot/DocumentRoot directories. If this is the case (.htaccess not allowed) you will have to kindly ask your web administrator to allow .htaccess files with authorization directives in your personal web directory. This can be achieved with AllowOverride AuthConfig directive and option.
Refference: http://weavervsworld.com/docs/other/passprotect.html

include/require in php



include/require in php


Method 1.

Use Absolute path with respect to file system(Not Server root). Best way is to Append file name with  $_SERVER['DOCUMENT_ROOT']" or $_SERVER[DOCUMENT_ROOT'"
For example:
include $_SERVER['DOCUMENT_ROOT']."/htdocs/project/conf.php"
where "/htdocs/project/" is the path of conf.php with respect to server root.

Method 2.

To include the files, path of the file should be  in the include path inside php.ini or file should be in same directory.
 Consider, for example, the following include path, which I use in my php.ini file ;

Windows

include_path = ".;c:php4pear;d:wwwphpinclude" ;


On a Unix server, it might look like this :

include_path = ".:/usr/local/php/lib/php:/home/kyank/phpinclude" ;

$_SERVER[] Array in php

$_SERVER[] Array in php

$_SERVER is an array containing information such as headers, paths, and script locations. The entries in this array are created by the web server. There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here. That said, a large number of these variables are accounted for in the » CGI/1.1 specification, so you should be able to expect those.
$HTTP_SERVER_VARS contains the same initial information, but is not a superglobal. (Note that$HTTP_SERVER_VARS and $_SERVER are different variables and that PHP handles them as such)

Indices

You may or may not find any of the following elements in $_SERVER. Note that few, if any, of these will be available (or indeed have any meaning) if running PHP on the command line.
'PHP_SELF'
The filename of the currently executing script, relative to the document root. For instance,$_SERVER['PHP_SELF'] in a script at the     address http://example.com/foo/bar.php would be/foo/bar.php. The __FILE__ constant contains the full path and filename of the current (i.e. included) file. If PHP is running as a command-line processor this variable contains the script name since PHP 4.3.0. Previously it was not available.
'argv'
Array of arguments passed to the script. When the script is run on the command line, this gives C-style access to the command line parameters. When called via the GET method, this will contain the query string.
'argc'
Contains the number of command line parameters passed to the script (if run on the command line).
'GATEWAY_INTERFACE'
What revision of the CGI specification the server is using; i.e. 'CGI/1.1'.
'SERVER_ADDR'
The IP address of the server under which the current script is executing.
'SERVER_NAME'
The name of the server host under which the current script is executing. If the script is running on a virtual host, this will be the value defined for that virtual host.
'SERVER_SOFTWARE'
Server identification string, given in the headers when responding to requests.
'SERVER_PROTOCOL'
Name and revision of the information protocol via which the page was requested; i.e. 'HTTP/1.0';
'REQUEST_METHOD'
Which request method was used to access the page; i.e. 'GET', 'HEAD', 'POST', 'PUT'.
Note:
PHP script is terminated after sending headers (it means after producing any output without output buffering) if the request method was HEAD.
'REQUEST_TIME'
The timestamp of the start of the request. Available since PHP 5.1.0.
'REQUEST_TIME_FLOAT'
The timestamp of the start of the request, with microsecond precision. Available since PHP 5.4.0.
'QUERY_STRING'
The query string, if any, via which the page was accessed.
'DOCUMENT_ROOT'
The document root directory under which the current script is executing, as defined in the server's configuration file.
'HTTP_ACCEPT'
Contents of the Accept: header from the current request, if there is one.
'HTTP_ACCEPT_CHARSET'
Contents of the Accept-Charset: header from the current request, if there is one. Example: 'iso-8859-1,*,utf-8'.
'HTTP_ACCEPT_ENCODING'
Contents of the Accept-Encoding: header from the current request, if there is one. Example: 'gzip'.
'HTTP_ACCEPT_LANGUAGE'
Contents of the Accept-Language: header from the current request, if there is one. Example: 'en'.
'HTTP_CONNECTION'
Contents of the Connection: header from the current request, if there is one. Example: 'Keep-Alive'.
'HTTP_HOST'
Contents of the Host: header from the current request, if there is one.
'HTTP_REFERER'
The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERERas a feature. In short, it cannot really be trusted.
'HTTP_USER_AGENT'
Contents of the User-Agent: header from the current request, if there is one. This is a string denoting the user agent being which is accessing the page. A typical example is: Mozilla/4.5 [en] (X11; U; Linux 2.2.9 i586). Among other things, you can use this value with get_browser() to tailor your page's output to the capabilities of the user agent.
'HTTPS'
Set to a non-empty value if the script was queried through the HTTPS protocol.
NoteNote that when using ISAPI with IIS, the value will be off if the request was not made through the HTTPS protocol.
'REMOTE_ADDR'
The IP address from which the user is viewing the current page.
'REMOTE_HOST'
The Host name from which the user is viewing the current page. The reverse dns lookup is based off the REMOTE_ADDR of the user.
NoteYour web server must be configured to create this variable. For example in Apache you'll need HostnameLookups On inside httpd.conf for it to exist. See also gethostbyaddr().
'REMOTE_PORT'
The port being used on the user's machine to communicate with the web server.
'REMOTE_USER'
The authenticated user.
'REDIRECT_REMOTE_USER'
The authenticated user if the request is internally redirected.
'SCRIPT_FILENAME'
The absolute pathname of the currently executing script.
Note:
If a script is executed with the CLI, as a relative path, such as file.php or ../file.php,$_SERVER['SCRIPT_FILENAME'] will contain the relative path specified by the user.
'SERVER_ADMIN'
The value given to the SERVER_ADMIN (for Apache) directive in the web server configuration file. If the script is running on a virtual host, this will be the value defined for that virtual host.
'SERVER_PORT'
The port on the server machine being used by the web server for communication. For default setups, this will be '80'; using SSL, for instance, will change this to whatever your defined secure HTTP port is.
NoteUnder the Apache 2, you must set UseCanonicalName = On, as well asUseCanonicalPhysicalPort = On in order to get the physical (real) port, otherwise, this value can be spoofed and it may or may not return the physical port value. It is not safe to rely on this value in security-dependent contexts.
'SERVER_SIGNATURE'
String containing the server version and virtual host name which are added to server-generated pages, if enabled.
'PATH_TRANSLATED'
Filesystem- (not document root-) based path to the current script, after the server has done any virtual-to-real mapping.
NoteAs of PHP 4.3.2, PATH_TRANSLATED is no longer set implicitly under the Apache 2 SAPI in contrast to the situation in Apache 1, where it's set to the same value as the SCRIPT_FILENAMEserver variable when it's not populated by Apache. This change was made to comply with the CGIspecification that PATH_TRANSLATED should only exist if PATH_INFO is defined. Apache 2 users may use AcceptPathInfo = On inside httpd.conf to define PATH_INFO.
'SCRIPT_NAME'
Contains the current script's path. This is useful for pages which need to point to themselves. The__FILE__ constant contains the full path and filename of the current (i.e. included) file.
'REQUEST_URI'
The URI which was given in order to access this page; for instance, '/index.html'.
'PHP_AUTH_DIGEST'
When doing Digest HTTP authentication this variable is set to the 'Authorization' header sent by the client (which you should then use to make the appropriate validation).
'PHP_AUTH_USER'
When doing HTTP authentication this variable is set to the username provided by the user.
'PHP_AUTH_PW'
When doing HTTP authentication this variable is set to the password provided by the user.
'AUTH_TYPE'
When doing HTTP authenticated this variable is set to the authentication type.
'PATH_INFO'
Contains any client-provided pathname information trailing the actual script filename but preceding the query string, if available. For instance, if the current script was accessed via the URLhttp://www.example.com/php/path_info.php/some/stuff?foo=bar, then$_SERVER['PATH_INFO'] would contain /some/stuff.
'ORIG_PATH_INFO'
Original version of 'PATH_INFO' before processed by PHP.