Altova Mailing List Archives


Re: [xml-dev] Re: Cookies at XML Europe 2004 -- Call for Particip ation

From: Robert Koberg <rob@------.--->
To: Elliotte Rusty Harold <elharo@-------.---.--->
Date: 1/6/2004 6:07:00 AM
Elliotte Rusty Harold wrote:

> At 7:05 PM -0800 1/5/04, Robert Koberg wrote:
> 
>>>  In a truly individualized situation all that's needed are URLs of 
>>> the form http://www.example.com/page.html?username=elharo
>>
>>
>>
>> Does your bank do this? If so, which bank do you use?
>> In other words, do you care if someone who knows or guesses your 
>> username can access your individualized situation?
> 
> 
> 
> You're missing a crucial point. The password which is also necessary for 
> access is not included in the URL. The URI identifies the resource but 
> it is not sufficient for access to the resource (unless that's what you 
> want of course. 


I must be missing something (definitely possible). If that URL is what 
tells the server that the request is for a resource you would not like 
others to access, then what does the password have to do with it? Or are 
you saying there is some server session being maintained (and so 
incurring all the overhead associated with it) (I doubt something like 
amazon maintains sessions)? If so, and you use a username to access the 
session, it still seems pretty insecure, at least during your active 
session.

...don't know if this is the best, but...
I generally have a user log in to verify as you mention. Then after 
authentication and before the next view is presented a user state object 
is created, populated and serialized using some random session 
identifier as the system id for the serialized object. Then the id is 
passed to a transformation to render a hidden input in the form to be 
submitted. The object can be deserialized on different machines to 
spread the load.

-Rob



> There are less sensitive situations where I might well 
> want to expose the contents of a personalized page to the world; e.g. my 
> wish list at amazon.com)
>

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.