SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 34
  1. #1
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    world
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up tracking session between two server

    Hi,
    How to track user session after they loging between more than one server?
    I know one method is to use centralized database but is there other methode that is faster&better ? What is the professional way to do that ?
    Thanks .

  2. #2
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dvddesign View Post
    What is the professional way to do that ?
    Don't use session state. It sounds harsh, but it's certainly possible, and it leads to better applications.

  3. #3
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    world
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    not clear! plz give some more details .

  4. #4
    SitePoint Enthusiast BeeStar's Avatar
    Join Date
    Apr 2008
    Location
    the Netherlands
    Posts
    27
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I guess he means don't use sessions (which store state on the server), but put the state in a cookie?


    Bee

  5. #5
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Location
    Oslo, Norway
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, I got a little lost there too. Sessions is inevitable in some settings, or do you have some other smart solution?

    Anyway, storing the state in cookies are not a good idea, as the user could easliy read them and learn how to bypass the login or change it's rights to superadmin or so.

  6. #6
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    theres as simple solution,

    store sessions in mysql memory type tables

    I use this method on several very large sites (much bigger than sitepoint) with several web frontend servers, much faster than default php storing sessions on disk and scales to few server clusters quite well

  7. #7
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Location
    Oslo, Norway
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thats what I do to, but you cant avoid the fact that it's still the users state stored somehow, in other words sessions.
    What I'm interested in is "Don't use session state.". I'm just wondering what kyberfabrikken puts in that.

  8. #8
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well theres no other way of storing a session or authentication other than a cookie on users browsers (well you can pass the sid in all urls but thats retarded)

  9. #9
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Location
    Oslo, Norway
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Exactly, thats why I want to know the answer to why I shouldn't use session states.

  10. #10
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    there are alot of scenarios where you need sessions and just cant avoid them

    user areas, shopping carts etc

    yes you dont need sessions if your developing some restfull api, or some read only service

    but majority of web applications need a way of tracking users between requests theres just no way about it

    i would like to see how would someone design a forum for example without using sessions

  11. #11
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A Secure Cookie Protocol (PDF) describes how to create a tamper proof cookie.

    Once a user logs in, and the cookie is set, its just a matter of verifying the cookie to confirm the user is logged in.

    Once your tracking users via the cookie, can remove all use of sessions.

  12. #12
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren View Post
    A Secure Cookie Protocol (PDF) describes how to create a tamper proof cookie.

    Once a user logs in, and the cookie is set, its just a matter of verifying the cookie to confirm the user is logged in.

    Once your tracking users via the cookie, can remove all use of sessions.
    erm "sessions" are dependant on cookies/tokens (either browser "cookie", flash "cookie" or parameter in url "cookie" )

    call it whatever you want but you are using a token/unique identifier sent by the client to provide a "session" theres no other way of doing this

  13. #13
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ionix5891 View Post
    erm "sessions" are dependant on cookies/tokens (either browser "cookie", flash "cookie" or parameter in url "cookie" )

    call it whatever you want but you are using a token/unique identifier sent by the client to provide a "session" theres no other way of doing this
    But we're talking about $_SESSION, and not using it. At least I thought we were.

    As the OP has a problem of having $_SESSIONs across multiple servers.
    And hence kyberfabrikken comment about not using session state.

  14. #14
    SitePoint Addict
    Join Date
    Jan 2008
    Posts
    203
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren View Post
    But we're talking about $_SESSION, and not using it. At least I thought we were.

    As the OP has a problem of having $_SESSIONs across multiple servers.
    And hence kyberfabrikken comment about not using session state.
    no were not talking about $_SESSION

    as i said earlier i use database backed session object (call it $Session) tho its not that hard to overwrite $_SESSION global to use database backend either instead of default filesystem storage which is slow and doesn't scale wll

    by default $_SESSION is populated using a small token php stores on user browser via cookie (take out wireshark and see for yourself, usually called phpsess cookie)

  15. #15
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ionix5891 View Post
    no were not talking about $_SESSION
    The original poster and following post seems to indicate we are, or should be. As he is taking about centralising state in a database. And the suggestion is to remove it, if possible.

  16. #16
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    lol confusion ITT

    it is my opinion that kyber is talking about the $_SESSION variable, and not sessions altogether. it's a given that you must track the state of a user and the best way to do that is with sessions. the default session saving method saves to the server's memory though, which obviously isn't cross-server. as ionix5891 points out, you can configure sessions to be stored on your database, which is IMO the best way to solve this problem.

  17. #17
    SitePoint Addict
    Join Date
    Dec 2007
    Posts
    348
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ionix5891 View Post
    store sessions in mysql memory type tables
    does using memory type tables give you a significant performance boost over myisam or innodb types?

  18. #18
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    writing to memory is usually faster than writing to the hard disk. that's what it's for, after all.

  19. #19
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I meant to avoid server side session state. It's correct, that in some cases, it's not possible, but on the other hand there are lots of cases where people use it, even when they don't need to. Obviously I don't know all the details about this particular application, but in my experience, a lot of server side session state can be eliminated, if you're willing to rethink your application a bit. For example, you can put the users credentials (username + password) in a cookie, and check them on each request. This has the added benefit of preventing session hijacking. A shopping cart is harder; One solution could be to upgrade it from session state to application state. Eg. insert into the database right away. You'd probably want to keep that information in any case, so you can make statistics about peoples shopping habits, even if they don't reach checkout.

  20. #20
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by old_iron View Post
    does using memory type tables give you a significant performance boost over myisam or innodb types?
    Good question. The apparent answer is yes, since memory is faster than disk, but there are caches in both the file system and the database server, so the end result might not differ much. As always with performance, measure before and after any tweaks.

  21. #21
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by old_iron View Post
    does using memory type tables give you a significant performance boost over myisam or innodb types?
    If your going memory route, I'd think memcache sessions would be better suited.

    Mainly because can distribute the data across many servers.

  22. #22
    SitePoint Addict
    Join Date
    Dec 2007
    Posts
    348
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    For example, you can put the users credentials (username + password) in a cookie, and check them on each request.
    The idea of not using server side session is appealing but surely the checking/processing each request would be inefficient compared to accessing $_SESSION or whatever?

    And what happens if the user doesn't use cookies.

  23. #23
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by old_iron View Post
    The idea of not using server side session is appealing but surely the checking/processing each request would be inefficient compared to accessing $_SESSION or whatever?
    Not necessarily true. You only have to verify the cookie on non safe methods (eg POST etc).

    For safe methods (GET, HEAD etc) intelligent fragment caching comes into play.

    Take this page, 99% is the same for everyone. And can be cached as such.

    The personal bits that make up the rest (Welcome, Ren You last visited... etc) can also be cached by the user+password cookie has to be part of the key for that cache fragment.

    PHP Code:
    $personalLogin $cache->get('login'$_COOKIE['token']);
    if (
    $personalLogin  === false)
    {
        ... 
    show the login form... 
    }
    else
        echo 
    $personalLogin 

    Quote Originally Posted by old_iron View Post
    And what happens if the user doesn't use cookies.
    They're kind of screwed anyway, unless you resort to putting tokens in the url.

  24. #24
    SitePoint Zealot Amenthes's Avatar
    Join Date
    Oct 2006
    Location
    Bucharest, Romania
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    I meant to avoid server side session state. It's correct, that in some cases, it's not possible, but on the other hand there are lots of cases where people use it, even when they don't need to. Obviously I don't know all the details about this particular application, but in my experience, a lot of server side session state can be eliminated, if you're willing to rethink your application a bit.
    Honestly, I don't get it. This seems to be the path CodeIgniter took with their
    session class which I also didn't get it. What's the main benefit of not storing
    data on the server side as opposed to client side?

    Quote Originally Posted by kyberfabrikken View Post
    For example, you can put the users credentials (username + password) in a cookie, and check them on each request. This has the added benefit of preventing session hijacking.
    But now some XSS hole means that I'm able to steal very sensitive
    information, both the username and password. Then use them to set that
    cookie's value on my computer. Further more, depending on how this data is
    stored in the cookie, I can even try to crack the password with some rainbow
    tables. But I'm sure you knew all this so you probably know something else
    that I don't.

    Quote Originally Posted by kyberfabrikken View Post
    A shopping cart is harder; One solution could be to upgrade it from session state to application state. Eg. insert into the database right away. You'd probably want to keep that information in any case, so you can make statistics about peoples shopping habits, even if they don't reach checkout.
    So basically is not about storing data on the server side, is about about storing
    temporarily data on the server side?

    I really don't see the advantages of client side storage over server side storage,
    so please elaborate a little bit.
    Last edited by Amenthes; Dec 5, 2008 at 01:39.
    I'm under construction | http://igstan.ro/

  25. #25
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Location
    Oslo, Norway
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    For example, you can put the users credentials (username + password) in a cookie, and check them on each request. This has the added benefit of preventing session hijacking.
    And I can't at all see how this is session hijacking proof. If I snatch your session I'm logged in as you. It even looks like it's a pretty valid cookie. Unless you at the same time validate with a session-id or so. But the only differens is that I have to steal two cookies. Or what am I missing her?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •