On 10/13/10 8:43 AM, Michael McCutcheon wrote:
> (replying at top this time) Only problem is that I'm using Basic
> authentication, which requires https to be secure.
>
> So this would mean that I'd have to basically force my whole service
> layer to be https if I did not use cookies.
you can use http digest for authentication which removes basic's major
disadvantage - sending credentials in plain text. its still not
foolproof, but depends on level of security which you need to achieve.
But if you don't use https yet, it might be sufficient for you.
>
> I just figured putting some encrypted value in a cookie (that also has
> a timestamp encoded into it) would be good enough...but I'm just
> learning some of this so I really don't know.
in general, you can do this and maybe add some kind of signature into
that cookie, on the other hand I don't recommend developing your
schemes; it might seem to be a good idea now, but imagine some other
client would like to access your service - he will need to implement it
as well.
Pavel
>
> thanks,
> Mike
>
>
> On 10/12/2010 11:17 PM, Imran M Yousuf wrote:
>> 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
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>