Instead of redirecting my users after login to index.php. I need code that will redirect back to it original page after successful login. I don't problem wit d login code. Thnks

when you check if the user has logged in, collect the $_SERVER['REQUEST_URI'] in a session and redirect to it.
Some people, even big sites, use a get variable. But IMHO, i think it is somewhat dangerous.

Thnks bro i'll give u a feedback

spikes C: when you check if the user has logged in, collect the $_SERVER['REQUEST_URI'] in a session and redirect to it.

But the session does not exist yet till after successful login. So which session do you refer to?

logica: But the session does not exist yet till after successful login. So which session do you refer to?

i always open sessions on all pages. language variable and general stuffs are saved there.

Login variables are only set when the person is logged in

I see. I don't know how it works in PHP, but this is what I expect when dealing with a standard web application:

Before a user logs on he is anonymous but has a session (which you can call anonymous session).

When he logs on, he then has a new (authenticated) session which is no longer the same as the anonymous session.

So if you had previously saved anything in the anonymous session you cannot access them in the new (authenticated) session; as they are not the same.

If the session you have pre-login and post-login are the same, I think that's a major security flaw.

I was just curious about how PHP uses sessions. By the way I am surprised PHP has no standard way of dealing with this as do quite a number of off-the-shelve web application frameworks.

logica: I see. I don't know how it works in PHP, but this is what I expect when dealing with a standard web application:

Before a user logs on he is anonymous but has a session (which you can call anonymous session).

When he logs on, he then has a new (authenticated) session which is no longer the same as the anonymous session.

So if you had previously saved anything in the anonymous session you cannot access them in the new (authenticated) session; as they are not the same.

If the session you have pre-login and post-login are the same, I think that's a major security flaw.

I was just curious about how PHP uses sessions. By the way I am surprised PHP has no standard way of dealing with this as do quite a number of off-the-shelve web application frameworks.

The only thing that makes a session anonymous is what it contains.
When you ope a session, it contains no data but has a session id which the user's browser always returns.

This session might contain the user's language choice, site theme choice, mobile/desktop view choice etc.
Therefore it contains general settings/site usage settings

Now, when the user logs in, you set some authentication variables/data. example the user's username, the user's access level, the user's id and a logged in flag. These new session variables would be removed when logged out.

Now for added security, PHP has a session function session_regenerate_id() which changes the user's session id and sends him the new one but still retains the old data.

PHP is actually not a framework, there're PHP frameworks which does so, infact all PHP frameworks has session managers

@Spikes C.. Please am a newbie in php.. I have a Question.

Assuming my site has five members and I want to Log them in when they enter their Username n Submit;

I Need a php code that can do this.. This is Just for Practise..

Is This Correct coz my Pc charger spoilt n I can't run it..

<?php

If(isset($_POST['submit']))
{
$username = $_POST['user'];

If($username=="frank" || $username=="jenny" || $username=="jessica" || $username=="amanda" || $username=="olivia"
{
echo "Welcome To Our Members Area";
}
else
{
echo "Incorrect Username.. Please Try Again";
}
}
?>

Snippets: @Spikes C.. Please am a newbie in php.. I have a Question.

Assuming my site has five members and I want to Log them in when they enter their Username n Submit;

I Need a php code that can do this.. This is Just for Practise..

Is This Correct coz my Pc charger spoilt n I can't run it..

<?php

If(isset($_POST['submit']))
{
$username = $_POST['user'];

If($username=="frank" || $username=="jenny" || $username=="jessica" || $username=="amanda" || $username=="olivia"
{
echo "Welcome To Our Members Area";
}
else
{
echo "Incorrect Username.. Please Try Again";
}
}
?>

This will definitely work but has some challenges.
1. I hope you would remember to sanitise your variables and use statements (with PDO or Mysqli).

2. What if you add more users, are you gonna be editing your code. Manage it with a DataBase.

3. I hope you remember the passwords (Pls always save a hashed password and mangle the hash salt.
I don't like storing salts so i use the username/email and mangle it with some CONSTANT characters)

spikes C:
PHP is actually not a framework, there're PHP frameworks which does so, infact all PHP frameworks has session managers

I know it isn't. And I was referring to redirect to original page; not session management. But it does appear that the way sessions are handled is flawed.

logica: I know it isn't. And I was referring to redirect to original page; not session management. But it does appear that the way sessions are handled is flawed.

How do you mean flawed, i can't really argue on that because i don't know any other web platform's method. To me i think its quite ok

@Spikes C.. Thanks Boss.. I've not entered d Mysql part..
Still @ d beginning stages of php.. Arrays, Variables.. I've not gotten to d Cookies n Session Part..

Snippets: @Spikes C.. Thanks Boss.. I've not entered d Mysql part..
Still @ d beginning stages of php.. Arrays, Variables.. I've not gotten to d Cookies n Session Part..

ok,just take it easy. PHP is quite fun and easy

@SPIKE C, i want to learn web applications, majorly for mobile. I only know html 4 and 5, css 2 and 3, with an intermediate level in javascript and a few jquery. I was told to learn jquerymobile and jquery and php. I have a starup project to work on (mobile web app). So what do you think i need to drop and i need to learn, so i can have goog knowledge of this , because i willl like to launch the application this year. And please help me with you contact details thanks...

dansmog++:
@SPIKE C, i want to learn web applications, majorly for mobile. I only know html 4 and 5, css 2 and 3, with an intermediate level in javascript and a few jquery. I was told to learn jquerymobile and jquery and php. I have a starup project to work on (mobile web app). So what do you think i need to drop and i need to learn, so i can have goog knowledge of this , because i willl like to launch the application this year. And please help me with you contact details thanks...

Web applications is not actually related to mobile applications.
Though some people misuse that statement for mobile enabled web applications (example facebook mobile i.e m.facebook.com) which is
just a web application that has a mobile view. This means that the user must have internet access before he can use it.

Now that part fits for jquery/jquerymobile and php for the backend. XHTML(5), css(3) and JavaScript.
Remember graceful degradation because most mobile browser cannot execute interactive JavaScript while some can't even execute javascript at all.

Now, the real mobile application is one that is installed in the users phone, example 2go, real football, binu etc.
They can't be developed with php at all (i'll come back to this).
They're developed with languages like Java(J2ME), C/C++, Objective-C etc.

But in this set, there is also 2 branches, one that is fully standalone (example real football) and one that needs internet connection
to function (e.g 2go, Binu). Therefore it gets it's data from web servers (therefore PHP is needed).


But to help you in your project, i'll need to know what the application does...or better still some general features it will possess. By
that, i can now suggest the languages you would need.

@SPIKES C, i will go for the first one which are jquery/mobile, php and the (x)html with css. I can move to major lang later on. The app that i want to create: you can use it to search for retail shops where you can buy something nearest to the location you are using the app from. And if you need any service like fashion design, just search, and i will give you the nearest place to get it done.

dansmog++:
@SPIKES C, i will go for the first one which are jquery/mobile, php and the (x)html with css. I can move to major lang later on. The app that i want to create: you can use it to search for retail shops where you can buy something nearest to the location you are using the app from. And if you need any service like fashion design, just search, and i will give you the nearest place to get it done.

ok, here's my advice. Build a full fledged web application for it first. Then port it into a mobile app. The mobile app will be more useful for the GeoLocation thingy

how do i port it into a mobile app?

dansmog++:
how do i port it into a mobile app?

A mobile app that sources it's data from the web...example 2go,facebook mobile etc

You guys are deviating from the OP's question.

I most say I agree with logica. . .

1. The way PHP handles sessions (or better still the way most programmers use session in PHP) introduce a major security hole in applications. Many don't realise that Sessions are 'super,super global variables'. Run as much as you can away from them. Use your DB, lang files, functions, classes to move data around. let sessions only store state data and not any other. My two cents


To the OP, as spike said get the SERVER['php_self'] but I'll say preferably append it to the login page as a url var. if you feel paranoid about that, then encrypt before you append, avoid sessions as much as possible. . . . .

pak: You guys are deviating from the OP's question.

I most say I agree with logica. . .

1. The way PHP handles sessions (or better still the way most programmers use session in PHP) introduce a major security hole in applications. Many don't realise that Sessions are 'super,super global variables'. Run as much as you can away from them. Use your DB, lang files, functions, classes to move data around. let sessions only store state data and not any other. My two cents


To the OP, as spike said get the SERVER['php_self'] but I'll say preferably append it to the login page as a url var. if you feel paranoid about that, then encrypt before you append, avoid sessions as much as possible. . . . .

Oga me, abeg ooo. you don bring another topic and am interested in it. i need comprehensive examples of what you're saying.
I don't really understand you

for sessions being super globals, the only risk i see in it is session fixation, which is actually very easy to stop (https)

then eeem, REQUEST_URI not PHP_SELF, because the page might contain get variables.

@spike, you are right - request_uri instead of php_self.

As regards session, I don't even know where to start.


Programming is all about CONTROL - avoid global variables if and when you can, and much more super global variables if and when you can. Many programmers don't know this but your browser actually determines how session variables are stored. Some pass sessions between tabs and some don't - so much for control

Sessions was introduced to counter the statelessness of http not to act as an information bank, the way most applications end up using it.
Misuse of sessions affects reusability and code maintenance. Make better use of your classes and DB.

pak: @spike, you are right - request_uri instead of php_self.

As regards session, I don't even know where to start.


Programming is all about CONTROL - avoid global variables if and when you can, and much more super global variables if and when you can. Many programmers don't know this but your browser actually determines how session variables are stored. Some pass sessions between tabs and some don't - so much for control

Sessions was introduced to counter the statelessness of http not to act as an information bank, the way most applications end up using it.
Misuse of sessions affects reusability and code maintenance. Make better use of your classes and DB.

i don't really think you understand what sessions are... do you mean setting cookies?

The only thing that ur browser knows about the session is your session ID.

and seriously, i don't actually understand why you're saying classes and DB against sessions. Pls, if possible, can you show me a sample code. Don't be offended, i really want to understand, I believe we all are learners

spikes C:

i don't really think you understand what sessions are... do you mean setting cookies?

The only thing that ur browser knows about the session is your session ID.

and seriously, i don't actually understand why you're saying classes and DB against sessions. Pls, if possible, can you show me a sample code. Don't be offended, i really want to understand, I believe we all are learners

Sure I don't . . . .


How would I explain this . . . . .

1. global vs local - Its advisable to always use local variables as opposed to globals when you can (we shouldn't be going thru this again man . . ) Sessions are 'super globals'.

2. code reuse/ modularity - I have seen cases where sessions are used inside functions and classes. I find it gross. The idea about modules is to ensure they can be used in several places and application when needed. If I do not have the same session bank as the module you were working on when developing the said class/function. then I'll be stuck reusing the said class in my module. I have had to refactor a lot of (other people's) code with this problem and it wasn't a nice experience

3. The browser issue I talked about involves a situation where some browsers store session information across every open tab while some don't. Yes, some versions of IE and some other browser actually keep session information on different tabs seperate. So if information about the current user is stored in a session, things can get quite messy. believe me I have been there. The issue is that with local variables you have ABSOLUTE control over how your variables are passed around.

4. Classes/DB - Best practice, IMHO is to only use sessions to store the IDENTITY of the current user/state. Info about the user should be retrieved from DB and preferably stored as an object. You get neater easier to maintain codes that way and most importantly. Variables don't just jump at the developer from anywhere . Don't u just get mad when you're working on someone else's code and you just start to wonder where a var suddenly appears from/ where it was set. Thats the 'effect' of session misuse. You just get variables lying around in your applications without knowing how they got there or what they hold. Making teamwork a nasty experience. Even with register_globals off. Its still sickening to have a session value being used in application without knowing exactly how it is set. As I said above best practice is to only store the IDs and use classes/DBs to fetch other info you need. This ensures that all the variables you are working with are actually local to module you're working on at that time.

I'll stuggle to explain better than this really . . . .

ah ah ah ah...Now i understand where you're coming from.
I am sorry for putting you in this mess of explanation, but atleast other people can learn from it.

pak:
1. global vs local - Its advisable to always use local variables as opposed to globals when you can (we shouldn't be going thru this again man . . ) Sessions are 'super globals'.

Yes, super globals are highly avoided but this can be wrong. There're a few basic things i store in my sessions.

.The logged in User's ID.
You can't actually get this variable from database without doing another username|password login (very bad to hold a user's password)

.The logged in flag (e.g $_SESSION['LOGGED_IN'] = TRUE)
.The logged in user's account status(e.g $_SESSION['ACTIVE'] = TRUE)
.The logged in user's email validation status(e.g $_SESSION['EMAIL_VALID'] = TRUE)
.The logged in user's username (e.g $_SESSION['USER'])if this is highly used around the application

Others might be unread messages count, unread notifications count etc.

The above are variables you use on every page load, do you expect someone to keep getting those data from the DB everytime.

pak:
2. code reuse/ modularity - I have seen cases where sessions are used inside functions and classes. I find it gross. The idea about modules is to ensure they can be used in several places and application when needed. If I do not have the same session bank as the module you were working on when developing the said class/function. then I'll be stuck reusing the said class in my module. I have had to refactor a lot of (other people's) code with this problem and it wasn't a nice experience

The OOP/reusable code problem. actually people don't use session variables in distributed codes, unless the particular module sets and uses it. You don't expect a session management class or even a login management class not to set, use and insert $_SESSION variable in their code....(maybe am misunderstanding you here)

pak:
3. The browser issue I talked about involves a situation where some browsers store session information across every open tab while some don't. Yes, some versions of IE and some other browser actually keep session information on different tabs seperate. So if information about the current user is stored in a session, things can get quite messy. believe me I have been there. The issue is that with local variables you have ABSOLUTE control over how your variables are passed around.

Now, i think you're misusing setting cookies and setting sessions.
My chairman, if the browser doesn't return the session ID, PHP will not identify the user, and your application will ask the user to login again.
Via setting cookies, always check if your cookie is set first and sanitise the returned value before using it.

pak:
4. Classes/DB - Best practice, IMHO is to only use sessions to store the IDENTITY of the current user/state. Info about the user should be retrieved from DB and preferably stored as an object. You get neater easier to maintain codes that way and most importantly. Variables don't just jump at the developer from anywhere . Don't u just get mad when you're working on someone else's code and you just start to wonder where a var suddenly appears from/ where it was set. Thats the 'effect' of session misuse. You just get variables lying around in your applications without knowing how they got there or what they hold. Making teamwork a nasty experience. Even with register_globals off. Its still sickening to have a session value being used in application without knowing exactly how it is set. As I said above best practice is to only store the IDs and use classes/DBs to fetch other info you need. This ensures that all the variables you are working with are actually local to module you're working on at that time.

Exactly, store only IDENTITY.

This part makes a whole lot'a sense and i can tell you, am guilty of this crime a few times (I think just once, am still trying to refactor that code)
I believe, that sessions should be used to store only sitewide/general application data
(e.g user's prefered display language, user's ID, logged in details)
Not modular application's variables (with exemptions like variables needed on every pageload (USE NAMESPACING))

But lets talk practical.
Database: the biggest problem in application development. DB is costly, very costly...this is why most developers store slightly reusable variables in sessions. Something that might be used only on even 2 or 4 seperate pages.
It's like debating DB normalization. In theory, it should be, practically, na your server go hear am

Another thing is documentation. A very important thing that is always left out.
It doesn't take much to describe what your super global variables are, when they're set and when they're used

I agree with most of what you wrote bro . . . .
but let me point out the parts I don't agree with.

spikes C:



Yes, super globals are highly avoided but this can be wrong. There're a few basic things i store in my sessions.

.The logged in User's ID.
You can't actually get this variable from database without doing another username|password login (very bad to hold a user's password)

.The logged in flag (e.g $_SESSION['LOGGED_IN'] = TRUE)
.The logged in user's account status(e.g $_SESSION['ACTIVE'] = TRUE)
.The logged in user's email validation status(e.g $_SESSION['EMAIL_VALID'] = TRUE)
.The logged in user's username (e.g $_SESSION['USER'])if this is highly used around the application

Others might be unread messages count, unread notifications count etc.

The above are variables you use on every page load, do you expect someone to keep getting those data from the DB everytime.

Yes i do, when it is neccessary. Most of my codes use OOP technique. I am more comfortable dealing with object properties and methods. I'll rather have the logged in user as an object. It just makes your coding easier thru the life span of your app. E.g. a point might come when you might need to have access to a user whose id is coming from another source - e.g from post or as a output of some other computational activities. Just plug in the id to your class and you're good. Or maybe some unique situations/modules where you have two different entities you are dealing with at a time. Just create two instances and your data is better managed.

The OOP/reusable code problem. actually people don't use session variables in distributed codes, unless the particular module sets and uses it. You don't expect a session management class or even a login management class not to set, use and insert $_SESSION variable in their code....(maybe am misunderstanding you here)

I keep telling ma peeps , never set/use sessions IN your classes. (The operative word here is IN). If your session needs to interact with you class. Let them be introduced as ARGUMENTS not in the class/method definition itself but rather in the code that calls the methods. That way the modularity of your code is preserved.

Now, i think you're misusing setting cookies and setting sessions.
My chairman, if the browser doesn't return the session ID, PHP will not identify the user, and your application will ask the user to login again.
Via setting cookies, always check if your cookie is set first and sanitise the returned value before using it.

You just dont get what am trying to explain here . . do you ? lets just let this one lie . . .

Exactly, store only IDENTITY.

This part makes a whole lot'a sense and i can tell you, am guilty of this crime a few times (I think just once, am still trying to refactor that code)
I believe, that sessions should be used to store only sitewide/general application data
(e.g user's prefered display language, user's ID, logged in details)
Not modular application's variables (with exemptions like variables needed on every pageload (USE NAMESPACING))

But lets talk practical.
Database: the biggest problem in application development. DB is costly, very costly...this is why most developers store slightly reusable variables in sessions. Something that might be used only on even 2 or 4 seperate pages.
It's like debating DB normalization. In theory, it should be, practically, na your server go hear am

Another thing is documentation. A very important thing that is always left out.
It doesn't take much to describe what your super global variables are, when they're set and when they're used

I agree with initial part of the last paragraph but the bolded ? . . . .

well constructed Classes are far easier to documented, PHPDOCS anyone ?

secondly, when you have an app with over a 1000 files, where do you start from in trying to locate where a session is set? and when they are used ? especially for those that set sessions indiscriminately in codes, which I am against.
But with classes your variables become local and you know where all your properties and methods are defined - in the library

pak: I agree with most of what you wrote bro . . . .
but let me point out the parts I don't agree with.

Yes i do, when it is neccessary. Most of my codes use OOP technique. I am more comfortable dealing with object properties and methods. I'll rather have the logged in user as an object. It just makes your coding easier thru the life span of your app. E.g. a point might come when you might need to have access to a user whose id is coming from another source - e.g from post or as a output of some other computational activities. Just plug in the id to your class and you're good. Or maybe some unique situations/modules where you have two different entities you are dealing with at a time. Just create two instances and your data is better managed.

I think this is rather easy, encapsulation. You're just saying, do not access the session variables directly but through objects.
You don't wanna see $_SESSION variable lying around everywhere. That's a very good point, Thank you for this.

pak:
I keep telling ma peeps , never set/use sessions IN your classes. (The operative word here is IN). If your session needs to interact with you class. Let them be introduced as ARGUMENTS not in the class/method definition itself but rather in the code that calls the methods. That way the modularity of your code is preserved.

Still makes a lot'a sense, seriously, you're teaching me OOP
But lets have an example, there's one class which cannot follow this rule. The session setter class(basically the login class. it needs to set the needed sessions, right?).
But maybe, as you might be thinking, the names and values of the sessions should be passed to a session setter class.
***I need your comment on this***

spikes C:



Still makes a lot'a sense, seriously, you're teaching me OOP
But lets have an example, there's one class which cannot follow this rule. The session setter class(basically the login class. it needs to set the needed sessions, right?).
But maybe, as you might be thinking, the names and values of the sessions should be passed to a session setter class.
***I need your comment on this***

Coding techniques differ. and different frameworks might implement things in diff ways.
Where I work, we use an in house developed framework for our apps.
In php for example, a loose code sample to deal with sessions might look like this in my app

to set

auth_obj = new testingClass(username, password) ;

$session[entityid] = auth_obj->getValidLogin() ; //techniques differ but here a value of 0 indicates invalid login, a value represents valid login and id of the entity



---------------


to retrieve user details after validating successfully logged in user on each page

$entitty_id = $_SESSION['entityid'] ;

$entity = new entityClass($entitty_id ) ;


// now with your entity object instantiated as local to your code, you can have access to any info you want about the entity without overusing sessions.

Just my two cents - more consistent, neater, easier to maintain



For brevity sake, i ignored stuffs like sanitizing inputs and so on . .. . .

pak:

Coding techniques differ. and different frameworks might implement things in diff ways.
Where I work, we use an in house developed framework for our apps.
In php for example, a loose code sample to deal with sessions might look like this in my app

to set

auth_obj = new testingClass(username, password) ;

$session[entityid] = auth_obj->getValidLogin() ; //techniques differ but here a value of 0 indicates invalid login, a value represents valid login and id of the entity

---------------


to retrieve user details after validating successfully logged in user on each page

$entitty_id = $_SESSION['entityid'] ;

$entity = new entityClass($entitty_id ) ;


// now with your entity object instantiated as local to your code, you can have access to any info you want about the entity without overusing sessions.

Just my two cents - more consistent, neater, easier to maintain
For brevity sake, i ignored stuffs like sanitizing inputs and so on . .. . .

Thats good, i have understood your concept.
But actually differs from what i thought you had in mind.

i would have loved it if the entityClass is the only one who knows what your session names are.
Therefore, you have only one place to edit the names if need be.

example

class entityClass(){

    private $user_id = 0;

    private function __construct($entity_id = 0){

        //the user probably checks for login before this
        if($entity_id = 0){$this->user_id = $_SESSION['USER_ID'];}

    }

}

example methods:

$entity = new entityClass();


$entity->get_id();
$entity->get_personal_details();

etc.

therefore, based on this your code.

$entitty_id = $_SESSION['entityid'] ;

$entity = new entityClass($entitty_id ) ;

I did rather just

$entity = new entityClass();

or

$a_different_entity = 2;

$entity = new entityClass($a_different_entity);

So, if it's a group development (which is the point of OOP )

No developer would include the $_SESSION variable in his code, except ofcourse, he knows what he's doing.




Finally, thanks for your tutorial. Really appreciate the time and effort. PHP lives on

SEUN, pls give us a CODE tag.

spikes C:

Thats good, i have understood your concept.
But actually differs from what i thought you had in mind.

i would have loved it if the entityClass is the only one who knows what your session names are.
Therefore, you have only one place to edit the names if need be.

example

class entityClass(){

private $user_id = 0;

private function __construct($entity_id = 0){

//the user probably checks for login before this
if($entity_id = 0){$this->user_id = $_SESSION['USER_ID'];}

}

}

example methods:
$entity = new entityClass();


$entity->get_id();
$entity->get_personal_details();
etc.

therefore, based on this your code.



I did rather just

$entity = new entityClass();

or

$a_different_entity = 2;

$entity = new entityClass($a_different_entity);

So, if it's a group development (which is the point of OOP )

No developer would include the $_SESSION variable in his code, except ofcourse, he knows what he's doing.




Finally, thanks for your tutorial. Really appreciate the time and effort. PHP lives on

SEUN, pls give us a CODE tag.

Makes sense . . . . .