Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: The sound of one cookie (not) authenticating

by sutch (Curate)
on Apr 03, 2001 at 16:40 UTC ( [id://69278]=note: print w/replies, xml ) Need Help??


in reply to The sound of one cookie (not) authenticating

How about not storing the session info in the URL? Instead, use forms extensively and store a session key in hidden fields. The URL then can be unique for each item and can be used by customers to send to others, and the hidden session key will not be included.

Replies are listed 'Best First'.
Re: Re: The sound of one cookie (not) authenticating
by arhuman (Vicar) on Apr 03, 2001 at 16:51 UTC
    Hidden fields are not more secure than parameters in the URL.
    ('show source' in your browser and everything is revealed...)
    But they look more 'professionnal' to me, even if I admit it's purely subjective and aesthetic...

    To me one way to secure a parameter would be to compute a hash (MD5,SHA1)
    of the parameter, the id session, and a private value (the customer ref in your base, for example)
    This way the link can't be cut and pasted later (beccause of the ID session)
    And link can't be faked given an id-session
    (as the private value is needed to compute the hash...)

    UPDATE :
    Just my 2 cents idea, Cookies would solve a lot of your troubles here,
    a lot of professionnal sites use them.
    And you may be surprised to see how well the customers accept this constraint
    ('Yes sir! your browser need to be cookie enabled to use our site.'
    is a sentence that I often say and it's always ok for my customers...)
    "Only Bad Coders Badly Code In Perl" (OBC2IP)
      Right, hidden fields are not secure. But Hero Zzyzzx was not concerned about secure sessions (I assume he would handle that through SSL). Instead the issue is that customers can mistakenly give away a link into their session just by giving the current URL to someone else.

      I don't understand how computing a hash will prohibit sessions from being transferred with URLs. Is the server or the browser going to compute the hash? If the browser, then JavaScript is required (and I believe the issue is not requiring the customer to use cookies, and possibly other optional browser features like JavaScript). If the server, then the URL is usable by any browser (which means that it can be given to others along with the hashed session ID).

        Instead the issue is that customers can mistakenly give away a link into their session just by giving the current URL to someone else.

        Ok I may have missed the question, it thought it was What's the best way to avoid Joe Blow having access to the original shoppers cart?.


        I don't understand how computing a hash will prohibit sessions from being transferred with URLs

        The hash use is only to one way to secure a parameter (verbatim from my post)
        A parameter hashed this way can't be used in another session nor faked.


        Is the server or the browser going to compute the hash?

        The server, beccause only the server knows the 'private value'...


        If the server, then the URL is usable by any browser (which means that it can be given to others along with the hashed session ID)

        As the hash value is bound to an id session you just can't use it with another session !
        So you can't reuse and old hash value nor even compute it (if you know your id session) to feed it to the server as you don't know the private value...

        "Only Bad Coders Badly Code In Perl" (OBC2IP)

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (6)
As of 2024-03-19 08:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found