On Nov 10, 2008, at 10:30 PM, Craig McClanahan wrote:
> Jeff Schmidt wrote:
>>
>> Hi Craig:
>>
>> I thought you might point out the statefulness of my REST API. :)
>> This was the most expedient way to provide such access with a very
>> session oriented application. We hope to move to a stateless REST
>> API in the future.
> That makes sense.
>
> But if you're in a webapp environment anyway, do you *really* need
> Jersey to do anything special beyond what is already possible? If
> your app creates a session in the usual way (you can get access to
> the HttpServletRequest via injection, so you can call the create
> session method on it), the app server will maintain the session for
> you.
Oh, I was thinking client-side Jersey. On the server side we're using
(kind of old versions of) Spring and Acegi Security. The application
has always been session oriented, along with concurrent licenses,
individual user access etc. Usage is recorded to some extent from
start of session to logout and billing is based on all of this. In
checking license availability, and accessing the database etc., there
is significant overhead in establishing a session with the application
then just creating an HTTP session on the app server.
Web services were not serious considered until more recently. We're
hoping for time for more infrastructure changes in 2009, where we can
make things more flexible. We also need to better understand how to
monetize web services vs. the classic session oriented interactive
access.
> Likewise for authentication ... if you're using something that
> leverages HTTP Basic, you should be able to configure the webapp
> security policy in web.xml to automatically trigger the 401
> responses. It's a little more intricate if you are doing some sort
> of "roll your own" login maintained by a session attribute, but a
> Jersey filter ought to be able to handle that already.
There is a separate Acegi filter chain configured to deal with the
REST API and its basic authentication (over HTTPS BTW).
Client-side though, failure to maintain an HTTP session will result in
the creation of a new session per REST request. For the user allowed a
single concurrent session, that will go badly. Likewise, a shared
concurrent license can be exhausted the same way, possibly denying
access to all users associated with that license. There are lots of
down sides to this implementation as compromises were made to make
some web services functionality available. The number of clients is
few at this time, but... :)
Take care,
Jeff
--
Jeff Schmidt
>
>
> Craig
>>
>> Cheers,
>>
>> Jeff
>>
>> On Nov 10, 2008, at 11:03 AM, Craig McClanahan wrote:
>>
>>> Jeff Schmidt wrote:
>>>>
>>>> This would be great! :)
>>>>
>>>> Might I be so bold as to hope for preemptive authentication and
>>>> cookie handling in order to maintain an HTTP session?
>>>>
>>> That is pretty bold, given that REST encourages you *not* to build
>>> stateful applications (i.e. where state is persisted between
>>> requests on the server, typically in a session) :-).
>>>
>>> But both of these, and SSL certification for that matter, seems
>>> like something you would want your servlet container to take care
>>> of in a webapp environment, so we're only talking about Java SE
>>> apps, right?
>>>
>>> Craig
>>>> Thanks!
>>>>
>>>> Jeff
>>>> --
>>>> Jeff Schmidt
>>>>
>>>> On Nov 10, 2008, at 1:38 AM, Paul Sandoz wrote:
>>>>
>>>>>
>>>>> On Nov 8, 2008, at 6:26 PM, Mike Jones wrote:
>>>>>
>>>>>> Hi Paul,
>>>>>>
>>>>>> Is it worth revisiting Basic and Digest authentication support
>>>>>> for the
>>>>>> client now that 1.0 is released?
>>>>>
>>>>> Yes.
>>>>>
>>>>>
>>>>>> I'd be more than happy to try and
>>>>>> help out.
>>>>>>
>>>>>
>>>>> Great. How do you want to proceed? Do you want to send a patch?
>>>>>
>>>>> Paul.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>
>> --
>> Jeff Schmidt