Do not take this in a bad way, but the word "stateless" is often used when describing the HTTP protocol, and yet most of web applications are inherently "stateful" (if you allow the expression) and implement mechanisms to work as such.
I understand it was decided in a developers meeting and that the never-closed sessions posed a big problem with a hard solution and all, but I (and it seems I was not the only one) had no notice about such a change in the mail lists, even though, as easy to fix as it is, it practically breaks any integration with other systems that used the REST endpoints. Anyway, let's hope that your arguments given in other mail thread (the one about the checkbox in Jira tasks, where you talk about the necessity of having a stable, trustworthy system), which I totally endorse, are definitely taken into account and help the whole community to avoid awkward situations like this one. Best regards Rubén 2012/3/15 Tobias Wunden <[email protected]> > Remember the session problem we were facing in 1.2, where each and every > REST request would create its own session that would never expire (since by > default, the embedded Jetty would not expire sessions)? It has then be > decided to make sure that after a call to a REST service, sessions should > be cleared, which is why your cookie is no longer valid and you need to > authentciate with each request. > > In my mind, this behavior is correct for REST services, as the word > "stateless" is often used when describing this protocol. And stateless in > this sense means no session. > > Tobias > > On 15.03.2012, at 12:46, Rubén Pérez <[email protected]> wrote: > > > Hello list, > > > > We've been extensively using the Digest authentication with Matterhorn > to integrate our home-made systems, particularly the Galicaster Capturer. > However, we've seen that we are somehow unable to authenticate with the 1.3 > release candidate. > > > > This is an example script we are using for testing: > > > > echo > "---------------------------------------------------------------------------------------------------------------------------------------------" > > echo > "-----------/welcome.html---------------------------------------------------------------------------------------------------------------------" > > echo > "---------------------------------------------------------------------------------------------------------------------------------------------" > > curl -v -c cookies.txt $server"/welcome.html" \ > > --get -H "X-Requested-Auth: Digest" \ > > --digest --user $username:$password \ > > echo > "---------------------------------------------------------------------------------------------------------------------------------------------" > > echo > "-----------/info/me.json--------------------------------------------------------------------------------------------------------------------" > > echo > "---------------------------------------------------------------------------------------------------------------------------------------------" > > curl -v -b cookies.txt $server"/info/me.json" > > > > > > , where me.json could be any other Matterhorn endpoint. > > > > What happened in 1.2 is that we could use the cookie received in the > "welcome.html" part to access to any other endpoints without further > authentication. However, in 1.3 we DO get a cookie and the resource (the > welcome.html page), but we remain being an anonymous user. That is > surprising, because anonymous users are not supposed to log in the welcome > page. > > > > On the other hand, we have seen that the integration tests perform the > authentication process every time they call an endpoint, instead of > obtaining a SESSIONID cookie once and then using it in the following calls > (perhaps the http client tries, the authentication fails and it logs in > again). > > > > I can't think of substantial changes in the authentication policy right > now, but I'd be glad to hear from you if this is an intended behavior, if > others can reproduce that problem and if you know of some changes in the > code that may have caused this issue. > > > > Thanks in advance for you input > > Rubén > > _______________________________________________ > > Matterhorn mailing list > > [email protected] > > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > > > > To unsubscribe please email > > [email protected] > > _______________________________________________ > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
