Hi Micheal,
I am not sure whether its a "bad practice" or not, but I, with all due
respect, prefer not to use either cookie or session from my web
service. Since authentication is taking place in every request,
cross-site scripting would require to know the username+password so
cookie would not be that much helpful ;) and if authentication is not
required I personally wouldn't mind cross site scripting :).
Regards,
Imran
On Wed, Oct 13, 2010 at 12:06 PM, Michael McCutcheon
<michael.mccutcheon_at_att.net> wrote:
> On 10/12/2010 10:03 PM, Imran M Yousuf wrote:
>>
>> Hi Micheal,
>>
>> On Wed, Oct 13, 2010 at 10:43 AM, Michael McCutcheon
>> <michael.mccutcheon_at_att.net> wrote:
>>>
>>> <skip />
>>> Some general questions:
>>>
>>> 1 - Is it a normal pattern to pass the authentication header over and
>>> over
>>> for the same user making multiple calls to service methods? Is there a
>>> way
>>> to make it so that this header only needs to be passed once for a given
>>> period of time?
>>>
>> Yes it is normal as server is stateless it is not suppose to remember
>> credentials from previous requests and should handle each request
>> independent of the last one. Where as your client can remember the
>> credentials having user (a person or program) not having to pass it
>> everytime unless s/he/it wishes to change the credentials.
>>
>>> 2 - For some of the service methods that don't change data (i.e. GET
>>> based
>>> calls), I still need the userid of the user making the call. What is the
>>> best way to pass this? A value in a cookie? If so, should it be
>>> encrypted
>>> to prevent cross site scripting attacks?
>>>
>> Well, there can be various ways of interpreting to determine the
>> "best" way for your cause. For example if your GET by user represents
>> a search you might consider passing the user id as query parameter.
>> Where as if your userid represents a directory or container of data
>> (e.g. tweets, feeds) you might consider it as PathParam. Now coming to
>> the point of cross site scripting you may use the Entity Tag if you
>> have to or a API Key concept or any other concept suiting you best :).
>> If I want my web service URI to not be templateable easily one way is
>> to encrypt+base64 the path params when exposing it and decrypt it to
>> understand the resource in query. To a web service consumer the URI is
>> meaningless as it is supposed to discover it against forming it.
>>
>> Regards,
>>
>> Imran
>>
>>> Just looking for some general guidance for how/when to use the
>>> Authentication headers, cookies, etc.
>>>
>>> thanks,
>>> Mike
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>
>
> Cool thanks for the info.
>
> One question though...can't I just set a cookie in the response in the first
> call and just require that cookie on all calls to other methods?
>
> i.e. implement an 'authenticate' method that sets the cookie in the response
>
> psuedo code:
>
> @POST
> public Response authenticate()
> {
> // only accessible if user is authenticated via basic authentication
> // if we are here then proper authorization header was provided
> // set cookie in response
> Cookie cookie = new Cookie("authCookie", someEncrypedValueWithUserId);
> return Response.cookie(cookie);
> }
>
> then all other method would simply require this cookie
>
> @GET
> public Response getSomeData(@PathParam("id") int id,
> @CookieParam("authCookie") String authenciateCookie)
> {
> if(authenciateCookie==null)
> {
> return Response.Unauthorized();
> }
> // do rest of work
> }
>
> Or is that considered bad practice?
>
> -Mike
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
--
Imran M Yousuf
Entrepreneur & CEO
Smart IT Engineering Ltd.
25/5B, Block F, Haji Chinu Miah Road Bylane
Joint Quarter, Mohammadpur
Dhaka - 1207, Bangladesh
Email: imran_at_smartitengineering.com
Twitter: @imyousuf - http://twitter.com/imyousuf
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557