Register

If this is your first visit, please click the Sign Up now button to begin the process of creating your account so you can begin posting on our forums! The Sign Up process will only take up about a minute of two of your time.

Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11
  1. #1
    Senior Member jbagley's Avatar
    Join Date
    Sep 2004
    Location
    Cape Town
    Posts
    845
    Member #
    7422
    How would one check on a page that a user is logged in?

    Im obviously going to use a session variable. So once the user enters his login information, I check it with his record in the database and make sure it authenticates. I then set the session variable.

    Now, what would I do on all the pages a user is supposed to be logged in to view? Check that the session variable exists?

    How would one do that? Can someone post the code here for me please...
    PHP Code:
    <?php session_start(); 
    //not too sure what to do now...
    ?>

  2.  

  3. #2
    Senior Member
    Join Date
    May 2003
    Location
    UK
    Posts
    2,354
    Member #
    1326
    hey dude.

    i took this code from my guestbook, and although one of you (i think it was some guy called jbagley..). you use the isset command.

    Code:
    <?php
    session_start();
    if (isset($_SESSION['name']))
    ?>
    example in pseudocode (structured english):

    if session[name] is set then
    welcome 'session[name]'
    else
    redirect to logon.php


    if you want me to expand, i will.

    basiclly, change name in the above code to whatever gets set when they logon.

  4. #3
    Senior Member jbagley's Avatar
    Join Date
    Sep 2004
    Location
    Cape Town
    Posts
    845
    Member #
    7422
    Quote Originally Posted by bfsog
    i took this code from my guestbook, and although one of you (i think it was some guy called jbagley..).
    Thanks for the help bfsog. Just wana know, what is it that I did? :classic:

  5. #4
    Senior Member
    Join Date
    May 2003
    Location
    UK
    Posts
    2,354
    Member #
    1326
    oh, i forgot to finish my sentence, erm you found a bug. i suppose i owe u one

  6. #5
    Member
    Join Date
    Dec 2004
    Posts
    67
    Member #
    8452
    Liked
    1 times
    You are setting a cookie. Try w3schools.
    Brian : This must be the physics department.
    Chris : That explains all the gravity.

  7. #6
    Senior Member visualAd's Avatar
    Join Date
    Jan 2003
    Location
    Slough, UK
    Posts
    201
    Member #
    434
    The PHP session module attempts to write a cookie to the client. The cookie is simply a unique hash generated by using the [phpfunction]md5[/phpfunction] function.

    When the client next requests a page on your site they send this cookie containing the hash, which PHP can then use to get the details pertaining to the individuals sessions.

    By default, any session varaibles you set in the $_SESSION array during your script are serialized and stored in a file on the server. You can change this behaviour, check the link in my sig.

    It is worth reading through and understatning the PHP documentation on sessions, you need to decide what to do if the user has disabled cookies (by default PHP set the SID constant which can be appended to the url query string) and security meaures you should use to prevent other people hijacking somone elses session.

    The PHP session module is ver versatile and there really is no excuse for not using it, you can control all aspects of session management:
    • Data paersistance accross multiple requests.
    • Set expiry times.
    • Control the frequency of garbage collection.
    • Completely customize the scope of the session cookie, its name, its life time, secure, the function used to generate the hash.
    • Customization of the sessions handler for complete control over where the session data is saved.

    http://www.php.net/session

  8. #7
    Senior Member jbagley's Avatar
    Join Date
    Sep 2004
    Location
    Cape Town
    Posts
    845
    Member #
    7422
    Thanks for all the help. VisualAd, what is then best practise with regards to user authentication?

    I will definitely read up on sessions etc.

  9. #8
    Senior Member visualAd's Avatar
    Join Date
    Jan 2003
    Location
    Slough, UK
    Posts
    201
    Member #
    434
    Quote Originally Posted by jbagley
    Thanks for all the help. VisualAd, what is then best practise with regards to user authentication?

    I will definitely read up on sessions etc.
    It depends on how secure you want it to be. In my opinion, if a session being comprimised will pose any threat to the users privacy, you must insit they use cookies - although they can be hijacked like the query string, it isn't as easy.

    You could fix the users IP address to the session but this is somewhat unreliable and is likely to yield both false positives and false negatives, the same with using the user agent string of the web browser.

    You can never make it impossible to hijack a session, but you can make it more difficult. Here some things you can do:
    • Have an expiration policy. If the amount of time between two requests is greater then the session expiration time then the use must re authenticate.
    • Prevent dictionary attacks by employing an account lockout policy. e.g no more than 5 login attempts every 15mins.
    • Don't transmit passwords and user identification infomation in plain text. Use a javascript function to enrypt them, md5 is a good method, there is plenty of source code out there.
    • Use an additional variable to keep track of a users session. A method I've used in the past is a request system. I set a variable in the session called request and appended a variable to all links called request. I then make sure that these match and increment it with every new request.

      This works well as long as your site is only being veiwed in one window or one tab. Ironically the very same system can be used in reverse to keep track of users who do use multiple tabs.
    • If you are going to fix the users IP address and user agent to the sesion be careful. Many ISP's will use proxy servers to cache content, so you need to make sure that it is the client requesting your script each time, by sending the appropriate headers.


    If you want real security, then use SSL. With SSL the data is encrypted and then signed. Only the reciveing party can decrypt it and the signature verifies the identity of the sender. Whats more this is all handled at the application layer and you need not concern yourself with implementing it.

  10. #9
    WDF Staff Wired's Avatar
    Join Date
    Apr 2003
    Posts
    7,672
    Member #
    1234
    Liked
    142 times
    visualAd, post that request thing to the UA thread in the php sec mailing list, i'd be interested how the others comment on it. can you explain a little more about it here in the meantime?

    BTW, the other points you made are dead on as to what's already been mentioned in the phpsec mailing list thread on UA so far.
    The Rules
    Was another WDF member's post helpful? Click the like button below the post.

    Admin at houseofhelp.com

  11. #10
    Senior Member visualAd's Avatar
    Join Date
    Jan 2003
    Location
    Slough, UK
    Posts
    201
    Member #
    434
    I originally created it to add extra security to a session. I basically created a variable called requestid and stored it in the session, then appended the request ID to the query string of all the links on the page. The flow is something like this:

    First Request / User Login
    1. Create a variable called requestid in the session and set it to 1.
    2. Append the variable to the query string of all links on the page.


    Subsequent requests.
    1. Check for the presence of a requestid, if not session may be compromised so reauthenticate the user.
    2. Check the requestid variable is identicle to the one stored in the session. Again, if not reauthenticate.
    3. Increment the requestid variable and re-append the new id to all links.

    This is by no means fool proof and can be by passed with relative ease, but it prevents unintentional hi-jacking of a session, especially where you are forced to do without cookies. The major drawback with it though became apparent when I started using Firefox. If you start opening multiple instances of the same site in different tabs and windows, the request ID's get out of sync, so I stopped using it.

    The drawback however did serve one benifit. By employing the use of a reqestid and a database, it allows you to store information about each request made. This is ideal in a tabbed browsing environment, because it means that operations involding multiple requests can be carried out in multi page/tabbed fashion without getting out of sync. The session data contains information about the current session, whereas the request stores information about the current operation.

    So I expanded the request class I originally made to add that functionality and now it works a dream. I havn't documnented it yet, but I've attached the class if you want to have a look. When I get the time I will document it and post it on my site.

    Although flawed I will post it on PHPSEC and see if they have any suggestions on how to build on it ....


Page 1 of 2 1 2 LastLast

Remove Ads

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT -6. The time now is 03:45 AM.
Powered by vBulletin® Version 4.2.3
Copyright © 2021 vBulletin Solutions, Inc. All rights reserved.
vBulletin Skin By: PurevB.com