Cookies know the exact path; on the machine, there’s a place where they are stored
they store the string that looks like the server address
they store the string that looks like the server address
NOTE: multiple browsers have their own mechanism for their cookies
- cookies are associated to the browser, (if you shut the window down, it doesn’t change what’s going on in the server…. When you hit a button on the site, it then connects to the server and then logs a user off)
Sessions requires:
1) Cookie matching data on the server (if the cookie stays on the machine
2) Log on status (log in/out)
Sessions are stored file-based, stored outside of the web root (safest place it could be)
· you don’t want hackers to see sessions information, don’t want that accessible to anyone else
What can be hacked:
- Number that is part of the session (unique self-incremented by server)
- Time: uniqueness of the session
Concept of “back ups”:
School makes these “tapes”: daily backed up, in case there are old worms (buried deep from back when)
Encrypting the password:
– passes the data onto the sessions page
session_start( ): high annoyance, every one of them may or may not need this
gets a nasty error msg (to tell you that you’re already started)
some use @ in front of session_start( )
gets a nasty error msg (to tell you that you’re already started)
some use @ in front of session_start( )
if(!isset($_SESSION)){session_start();} // superglobal here, if session hasn't start, start here
$sCustomerID = trim($row['CustomerID']); //Grab the Customer's unique ID, from a database
$_SESSION["sCustomerID"] = $sCustomerID; //Enter variable into session variable
$_SESSION["FirstName"] = $FirstName;
$_SESSION["Email"] = $Email;
echo $_SESSION["Email"]; // to see what comes in
session_data: when you store it here, it is accessible
cookie_data:
config file: loads the constants (gets called every time and cannot be changed)
everything that the pages use are now totally wiped cleaned
everything that the pages use are now totally wiped cleaned
Application level:
To banish/lock someone from a web page: (NOTE: this goes in the private page, not in public)
if(!isset($_SESSION)){session_start();}
if(!isset($_SESSION['sCustomerID'])) // do they have a customerID, do they exist?
{ //no session var
myRedirect("login.php?msg=5"); //send user back to login page, as session has timed out
} // puts a msg back to the log in page, gotta be a “doorstep”
if(!isset($_SESSION['sCustomerID'])) // do they have a customerID, do they exist?
{ //no session var
myRedirect("login.php?msg=5"); //send user back to login page, as session has timed out
} // puts a msg back to the log in page, gotta be a “doorstep”
session would have a time-out, so that it rules out hackers… makes it private
NOTE: rounded ones are NOT pages (they are doorstep “process” prompts)
All orange (are protected, yellow is log-in protected)
HOW to LOG IN:
HOW to LOG IN:
1) Username: usually an email (guaranteed uniqueness, domain, contactable to send msg test)
developer@example.com
developer@example.com
2) password: asdfasdf
Folder for application:
One table & one folder: easy to get rid/move or install somewhere else
root should be reserved to client’s actual pages
Prefix “admin” indictor for which files can make it locked out (with the “if” statement)root should be reserved to client’s actual pages
One-way encryption: put data in, no one can get it back (password “SHA” will jumble it up)
Password gets asked, then compared with mangled version to allow access
admin_login:
Application root:
NOTES:
ENUM - Privilege ENUM('admin','superadmin','developer') DEFAULT 'admin',
Note: superadmin: client
admin: you the developer
In-class DIRECTIONS:
· Drag admin folder into the application folder
· Copy admin_only_inc.php into “inc_700” folder
· Look at nmAdmin.sql >
· inc_700 implies that there is ONLY 1 folder that contains these sets of info
line 41 in config_inc is commented out since we don’t want to keep it permanently
line 41 in config_inc is commented out since we don’t want to keep it permanently
