Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Secure Session Management

by valdez (Monsignor)
on Sep 06, 2002 at 18:10 UTC ( #195720=note: print w/replies, xml ) Need Help??


in reply to Secure Session Management

If you can use mod_perl, then try with Apache::AuthCookie; module's documentation is very clear about its benefits, it says:

  1. The client doesn't *have* to pass the user credentials on every subsequent access. If you're using passwords, this means that the password can be sent on the first request only, and subsequent requests don't need to send this (potentially sensitive) information. This is known as "ticket-based" authentication.
  2. When you determine that the client should stop using the credentials/session key, the server can tell the client to delete the cookie. Letting users "log out" is a notoriously impossible-to-solve problem of AuthBasic.
  3. AuthBasic dialog boxes are ugly. You can design your own HTML login forms when you use AuthCookie.

I found it quite interesting :) But this solves only half of your problem: you need also session management, right? Apache::Session could be an answer, but you may need to put some glue between these two modules.

Ciao, Valerio

Replies are listed 'Best First'.
Re: Re: Secure Session Management
by BrowserUk (Pope) on Sep 06, 2002 at 19:14 UTC

    I'm not sure I understand this bit

    When you determine that the client should stop using the credentials/session key, the server can tell the client to delete the cookie. Letting users "log out" is a notoriously impossible-to-solve problem of AuthBasic.

    Isn't the usual reason a server decides to 'log a client off' because of session timout after 20 mins or so? This normally occurs when they have simply moved on to another site or disconnected without informing the server they are doing so... in which case, there is not client to send the instruction to delete the cookie.

    Also, how does the server 'tell the client'? I know there is such a thing as 'server push', but I didn't think this had ever made much of an impact. Besides...

    The other way the timeout can occur is if the user is reading something long. If I was doing this and the server suddenly decided to 'send' me a 'your logged off' page, I don't think I would use that site again in a hurry.

    I think anything that relies on cookies is gonna limit your audience severely, and more so as new users become aware of the potential for misuse of cookies. The latest browsers that allow cookie control on a site-by-site basis mitigate this problem somewhat, but that requires users knowledgable to distinguish between sites they can trust and those they cannot. Unfortunately, things like the Trust-E symbol aren't worth the band-width that it takes to transmit them, as very little verification is done. ANd what verification is done, is done against the site "privacy policy", which invariably can be paraphrased as:

    <rant>

    {20k omitted}...of course, we won't use your private details for anything bad, but if we can find a way of screwing some commercial gain by using them to promote some aspect our, or our partners (Read:anyone who will pay us) businesses to you, we will! And by having said this here, hidden on another page linked from every page, in totally oblique, long-winded, legal terminology and frustratingly tiny print, we've effectively covered our arses should you ever discover what we are doing.

    </rant>


    Well It's better than the Abottoire, but Yorkshire!

      Your worries about compatibility can be solved using different solutions to the same problem. If you don't want cookies, then just use something like Apache::SessionManager, which can handle sessions inside URIs.

      Of course, this doesn't resolve privacy issues, as you can imagine, because it is still possible to track a user even without cookies. On the other hand, it would be quite impossible to put something in a basket on Amazon or build something like PMonks, without something holding a state. So there is no escape, except honesty.

      BTW, it is possible to expire AuthBasic accounts. Using cookies, just send an empty cookie (delete it) and the user will not enter your site without re-authentication. Under AuthBasic, just disable an account inside your htpasswd file. But you will need some more glue :-))

      Ciao, Valerio

        Sorry for the rant about E-Trust and privacy policies. Valid rant, wrong time/place.

        My original point about expiring sessions by deleting cookies still holds true though.

        • User logs on, you give him a cookie
        • User does some stuff
        • User disconnects or moves to another site.
        • Server expires session, but can't send a 'delete cookie', blank cookie, or 'Your logged off' msg to the client (using server push or not) because the client isn't there. No communication path at all.
        • User returns a week later, issues a request against the client for whatever page they were on when here last (using a bookmark they made for example). The request arrives at the server with the auth. cookie still intact.

          Unless of course, the cookie was set to expire within a few minutes or hours, in which case the client won't send it. In this case, no action is required by the server to "determine a session is over" and it doesn't need to "tell the client to delete the cookie"?

        Of course, this has flaws too. Cookies are text. Expiration times can be changed at the client. It therefore requires that the cookie carry an external and an internal expiration, with the internal expiration suitably encoded that edits can be detected.

        My point was simply that if the session expires because the connection is broken, there is no mechanism by which the server can tell the client to delete the cookie.



        Well It's better than the Abottoire, but Yorkshire!
      Also, how does the server 'tell the client'? I know there is such a thing as 'server push', but I didn't think this had ever made much of an impact.

      The server "tells" the client (to delete the session cookie) in response to a request from the client. In the timeout case, the server can also refuse to handle the request.

      Push isn't needed. If a web application really, really needs to know on a minute-by-minute basis whether the server thinks the client is logged in, use a hidden frame that refreshes on a periodic basis, and expire the session cookie on refresh. You can also include a javascript snippet to communicate "I've been logged out" to some non-hidden frame element.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://195720]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (7)
As of 2020-01-20 09:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?