LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 06-18-2017, 08:49 PM   #1
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 1,266

Rep: Reputation: 201Reputation: 201Reputation: 201
Smile PHP login session


Hello guys, just starting to get my hands wet on PHP.

Here's my question, after user authentication I want to redirect it to a page. Redirection works without any issue.

I'm just wondering what if the user bookmark the URL, how do I check whether the user has login or the session is still active?

How to create a URL with a PHP session? Is it safe?

Thanks for any ideas.
 
Old 06-18-2017, 11:30 PM   #2
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 4,341
Blog Entries: 1

Rep: Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331
If the user bookmarks the page, and the page does not authenticate them itself, they will get it next time just for the asking.

Oddly enough, I saw this article earlier today, and was able to find it again. Read Tip #3, it is right on topic.

Whatever form of authentication you use, each protected page must authenticate the user on each request.

Typically, you would set a token (cookie) on the client upon successful login. Each successive page request would then validate that the token is received and that it is valid before delivering the content. The token must be secure against being forged or reused at a later time.

Last edited by astrogeek; 06-18-2017 at 11:34 PM.
 
2 members found this post helpful.
Old 06-19-2017, 01:54 AM   #3
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 1,266

Original Poster
Rep: Reputation: 201Reputation: 201Reputation: 201
Hi Astrogeek, thank you so much for your reply.

I actually haven't start coding and not yet familiar with PHP, it just cross my mind. So before I delve into it I tried to think all possibilities that might happen.

Cookie is one thing but cookie can easily be tampered, i'm looking into sessions and putting it to URL.

Sessions always change but i'm not sure how to do it or if it is secure.

I read somewhere also about session fixation.

A beautiful world of programming with a lot of nastiness around it.
 
Old 06-19-2017, 10:34 AM   #4
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,216
Blog Entries: 4

Rep: Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765
I suggest that you "surf" a number of topics before you dive into the PHP (or, any specific) language. For instance, be sure that you understand how logins are handled ... how cookies are set and retrieved ... how redirects work, and that you know that a redirect-response won't at the same time set a cookie.

There is a tremendous amount of material out there on these subjects. Most of them are specific to one programming-language or another, on the client-side or the host-side or both, but the concepts are fundamental and therefore universal.

Approach your learning this way: "first, understand exactly what you want the computer to do, and exactly how it will all work out between the two computers in all the possible situations." And, "be sure that you understand the situations clearly." Then, and only then, start thinking about <<PHP|Ruby|Perl|...>>. Because these are only various tools for the implementation of it.

Finally: also remember that most languages have rich libraries of "contributed code" which may allow you to "grab 80% of the solution to 'your' problem off the shelf," so that you can actually focus on "the other 20% that is actually particular to 'your' problem! The proverbial "80/20 Rule" is very significant here.
Quote:
Actum Ne Agas: Do Not Do A Thing Already Done.™
Alternatively, you can prowl around the source-code of their "off-the-shelf solution" and see for yourself how it works ... knowing that it does. Hey, why build it from scratch when you can steal it?

Last edited by sundialsvcs; 06-19-2017 at 10:38 AM.
 
1 members found this post helpful.
Old 06-19-2017, 11:58 AM   #5
Laserbeak
Member
 
Registered: Jan 2017
Location: Manhattan, NYC NY
Distribution: Mac OS X, iOS, Solaris
Posts: 508

Rep: Reputation: 142Reputation: 142
Cookies are the usual way. But they need to be a randomly selected cookie and you need to store it on your side and look it up when someone comes back and submits the cookie to you. In other words, you don't make the cookie contain all the information for login.
 
1 members found this post helpful.
Old 06-19-2017, 08:15 PM   #6
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 1,266

Original Poster
Rep: Reputation: 201Reputation: 201Reputation: 201
Lightbulb

Quote:
Originally Posted by sundialsvcs View Post
I suggest that you "surf" a number of topics before you dive into the PHP (or, any specific) language. For instance, be sure that you understand how logins are handled ... how cookies are set and retrieved ... how redirects work, and that you know that a redirect-response won't at the same time set a cookie.

There is a tremendous amount of material out there on these subjects. Most of them are specific to one programming-language or another, on the client-side or the host-side or both, but the concepts are fundamental and therefore universal.

Approach your learning this way: "first, understand exactly what you want the computer to do, and exactly how it will all work out between the two computers in all the possible situations." And, "be sure that you understand the situations clearly." Then, and only then, start thinking about <<PHP|Ruby|Perl|...>>. Because these are only various tools for the implementation of it.

Finally: also remember that most languages have rich libraries of "contributed code" which may allow you to "grab 80% of the solution to 'your' problem off the shelf," so that you can actually focus on "the other 20% that is actually particular to 'your' problem! The proverbial "80/20 Rule" is very significant here.

Alternatively, you can prowl around the source-code of their "off-the-shelf solution" and see for yourself how it works ... knowing that it does. Hey, why build it from scratch when you can steal it?
Hi Sundialsvcs, to be honest I'm not starting from scratch. Yes, there's ton of examples in PowerPoint, PDF and some other formats.

I've seen that Symfony, Laravel, Yii and other framework can do it. I will be hosting the PHP program on Raspberry Pi, if it's quite loaded with framework it may not have a good performance.

I'm trying to see whether some pure PHP solution can do the job.

Thanks for your reply, good insight. Cheers!
 
Old 06-19-2017, 08:17 PM   #7
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 1,266

Original Poster
Rep: Reputation: 201Reputation: 201Reputation: 201
Smile

Quote:
Originally Posted by Laserbeak View Post
Cookies are the usual way. But they need to be a randomly selected cookie and you need to store it on your side and look it up when someone comes back and submits the cookie to you. In other words, you don't make the cookie contain all the information for login.
Thanks Laserbreak, I will do some test with Cookie and Sessions.

Agree with you, Cookie should be the simple way.
 
Old 06-20-2017, 03:32 AM   #8
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 4,341
Blog Entries: 1

Rep: Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331Reputation: 2331
Quote:
Originally Posted by JJJCR View Post
Thanks Laserbreak, I will do some test with Cookie and Sessions.

Agree with you, Cookie should be the simple way.
Be sure to understand "what" the cookie is in this scheme of things and what properties it must have in order to do the job. Avoid thinking that the cookie is the important thing - it is not. A cookie, or a URL encoded with a session identifier, or a shared secret can all perform the same job, and all must be verified as non-fake on each use. All are only tokens which represent something else. The important thing is that the information they carry cannot be counterfeited and is verifiable on each use.

Always remember, the cookie or other token that comes from the client can be trivially faked - never trust them! If you send a cookie which says "logged-in" and accept that as proof, then all a cracker must do is send you a cookie which says "logged-in" and you cannot tell the difference!

On the other hand, if you send a cookie with a long and unique identifier which you also record in your private notebook, then when a visitor gives the cookie back to you, you only accept it if it is listed in your notebook! That is one mechanism which can make them un-fakeable. The same mechanism applies to cookies and session encoded URLs.

As sundialsvcs pointed out, first learn "what" is required, and only then think about "how" to do that using some mechanism such as a cookie or a session encoded URL... then write code.

Good luck!
 
1 members found this post helpful.
Old 06-20-2017, 04:39 AM   #9
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 1,266

Original Poster
Rep: Reputation: 201Reputation: 201Reputation: 201
Lightbulb

Quote:
Originally Posted by astrogeek View Post
Be sure to understand "what" the cookie is in this scheme of things and what properties it must have in order to do the job. Avoid thinking that the cookie is the important thing - it is not. A cookie, or a URL encoded with a session identifier, or a shared secret can all perform the same job, and all must be verified as non-fake on each use. All are only tokens which represent something else. The important thing is that the information they carry cannot be counterfeited and is verifiable on each use.

Always remember, the cookie or other token that comes from the client can be trivially faked - never trust them! If you send a cookie which says "logged-in" and accept that as proof, then all a cracker must do is send you a cookie which says "logged-in" and you cannot tell the difference!

On the other hand, if you send a cookie with a long and unique identifier which you also record in your private notebook, then when a visitor gives the cookie back to you, you only accept it if it is listed in your notebook! That is one mechanism which can make them un-fakeable. The same mechanism applies to cookies and session encoded URLs.

As sundialsvcs pointed out, first learn "what" is required, and only then think about "how" to do that using some mechanism such as a cookie or a session encoded URL... then write code.

Good luck!
Thanks, Astrogeek. I will keep that on mind. I will do a simple cookie first, then I will code all the functionality. If everything works fine, then I will go back on how to secure the mechanism of authentication. Anyway, first roll-out will just be on the local network.

Cookie with the PHP session-id for the mean time but it's not enough I know, hashing will be more secure.

My head is on the water right now, but still breathing fine. Thank you guys for all your insights.
 
Old 06-20-2017, 08:53 AM   #10
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,216
Blog Entries: 4

Rep: Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765
Conceptually, the cookie is just a "nonce" it could be a UUID, say which leads you to your session-table. (Be sure to use parameters in your SQL query since a common trick is to embed a Bobby Tables attack in the session-cookie value!) You should record other supporting information such as the IP-address of the client and check for agreement. All server-side information is stored in the session-data referenced by the session-token; none is provided by the client. The client is never trustworthy.

But once again: "canned, off the shelf session-handlers" are very readily available.
 
2 members found this post helpful.
Old 06-20-2017, 08:10 PM   #11
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 1,266

Original Poster
Rep: Reputation: 201Reputation: 201Reputation: 201
Post

Quote:
Originally Posted by sundialsvcs View Post
Conceptually, the cookie is just a "nonce" it could be a UUID, say which leads you to your session-table. (Be sure to use parameters in your SQL query since a common trick is to embed a Bobby Tables attack in the session-cookie value!) You should record other supporting information such as the IP-address of the client and check for agreement. All server-side information is stored in the session-data referenced by the session-token; none is provided by the client. The client is never trustworthy.

But once again: "canned, off the shelf session-handlers" are very readily available.
Wow, thanks for the ideas. This is gonna be exciting. The project actually also includes a hardware interface, I initially thought that this project would be a piece of cake but I slowly get into the details. I realize that I'm getting into trouble.
 
Old 06-20-2017, 08:36 PM   #12
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,216
Blog Entries: 4

Rep: Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765Reputation: 2765
I repeat: there are a wide variety of "frameworks" for PHP and for every other imaginable programming language. They are not "all like WordPress!" Some simply provide the basic pieces of "what any and every web server-side application needs," specifically including session-handling and a variety of defensive measures. Don't bother to do what has already been done.
 
Old 06-21-2017, 01:12 AM   #13
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 1,266

Original Poster
Rep: Reputation: 201Reputation: 201Reputation: 201
Post

Quote:
Originally Posted by sundialsvcs View Post
I repeat: there are a wide variety of "frameworks" for PHP and for every other imaginable programming language. They are not "all like WordPress!" Some simply provide the basic pieces of "what any and every web server-side application needs," specifically including session-handling and a variety of defensive measures. Don't bother to do what has already been done.
Thanks Sundialsvcs, I keep trawling the web there are actually examples on how to do this without any framework.

Framework is really good but I won't be able to fully utilize the whole framework. So, I will do it with PHP and MySQL together to check and secure session authentication.
 
Old 06-21-2017, 05:52 PM   #14
scasey
Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 5.11
Posts: 279

Rep: Reputation: 97
Have you considered apache mod_auth? The security will only persist for the life of the browser session. Bookmarking a page, then closing the browser, then using the bookmark later will require re-login.

One has to manage maintaining the AuthUserFile of users and passwords, but can presume in PHP (or other cgi) code that anyone who is there has been authenticated. The apache auth works at the directory level and can be done using .htaccess files if you don't have access to httpd.conf

Thoughts?
 
1 members found this post helpful.
Old 06-21-2017, 08:29 PM   #15
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 1,266

Original Poster
Rep: Reputation: 201Reputation: 201Reputation: 201
Lightbulb

Quote:
Originally Posted by scasey View Post
Have you considered apache mod_auth? The security will only persist for the life of the browser session. Bookmarking a page, then closing the browser, then using the bookmark later will require re-login.

One has to manage maintaining the AuthUserFile of users and passwords, but can presume in PHP (or other cgi) code that anyone who is there has been authenticated. The apache auth works at the directory level and can be done using .htaccess files if you don't have access to httpd.conf

Thoughts?
Thanks for the idea, I think it makes sense to use Apache since the site is hosted by Apache anyway.


I will check on this, thanks again. Cheers!
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
does anybody knows what this means? ptymonitor: pam_unix(login:session): session opened for user root by (uid=0) osalas Red Hat 3 08-15-2016 09:01 PM
Are PHP session variables held in memory when you leave a PHP site? Locura Programming 11 11-16-2008 08:37 PM
PHP Session Ending? wh33t Programming 4 12-24-2006 03:08 PM
php session richard22 Programming 2 10-26-2004 05:50 AM
Login session ust Linux - General 3 04-17-2003 07:41 AM


All times are GMT -5. The time now is 06:24 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration