Tobias, We are using the CAS-enabled security configuration that's provided in the source code.
That being said, I don't think I follow. I thought all requests passed through Spring security, and it let them go or not according to the rules defined in that xml file you pointed out. Just in case, those are the (I think) relevant lines: <sec:intercept-url pattern='/info/me.json' method="GET" > access='ROLE_ANONYMOUS, ROLE_USER' /> > <sec:intercept-url pattern='/search/**' method="GET" > access='ROLE_ANONYMOUS, ROLE_USER' /> However my question was more specific: when I access the /info/me.jsonusing the digest authentication mechanism: curl *--digest -u login:password -H "X-Requested-Auth: Digest" * > http://our.server.url/info/me.json (where login and password are the credentials of the digest user defined in config.properties), should or should not I see the info about the login user returned? Because currently, no matter what, it always returns the "anonymous" user, which tells me that this endpoint is not working for the digest user or that we are doing something wrong. Best regards Rubén 2012/6/25 Tobias Wunden <[email protected]> > Ruben, > > you will only get a user in the SecurityService, if the Url you are > accessing is protected by Spring security. Note that protected does not > necessarily mean restricted, access may as well be granted to > ROLE_ANONYMOUS, meaning that login is not required, but Spring Security > will still filter the request. > > If the urls you are accessing are not yet part of the spring configuration > (etc/security/mh_deafult_org.xml), then this should be reported as a bug > and corrected > > Tobias > > > On 25.06.2012, at 17:02, Rubén Pérez <[email protected]> wrote: > > Dear list, > > Rubén (one colleage of mine, not myself) is at the moment working in a > script for massive content migration between two Matterhorn installations. > However, he (actually, we) have observed a weird behaviour when using the > digest authentication with the endpoints that can be accessed publicly. > > We are using a line like this: > > curl --digest -u login:password -H "X-Requested-Auth: Digest" >> http://our.server.url/a/certain/endpoint > > > to access some Matterhorn endpoints, but we are observing that accessing > private endpoints (endpoints that require authentication) such as > system/console or welcome.html... > > curl --digest -u login:password -H "X-Requested-Auth: Digest" >> http://our.server.url/system/console > > curl --digest -u login:password -H "X-Requested-Auth: Digest" >> http://our.server.url/welcome.html > > > ...works like a charm the server returns the expected contents. However, > when we do the same with public endpoints... > > curl --digest -u login:password -H "X-Requested-Auth: Digest" >> http://our.server.url/info/me.json > > > we get the following answer: > > {*"username":"anonymous","roles":["ROLE_ANONYMOUS"]*,"org":{"id":"mh_default_org","anonymousRole":"ROLE_ANONYMOUS","name":"Opencast >> Project","adminRole":"ROLE_ADMIN","properties": >> "logo_small":"\/img\/OpencastLogo.png","adminui.i18n_tab_users.enable":"true","engageui.link_download.enable":"true","logo_large":"\/img\/MatterhornLogo_large.png","adminui.i18n_tab_episode.enable":"true"}}} > > > , which means that the endpoint does NOT view us as the digest user > "login", but as an anonymous user. The same happens when we use: > > >> curl --digest -u login:password -H "X-Requested-Auth: Digest" >> http://our.server.url/search/episode.xml > > > , we get the following results: > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> >> <ns2:search-results xmlns:ns2="http://search.opencastproject.org"; >> xmlns:ns3="http://mediapackage.opencastproject.org"; searchTime="1" >> total="0" limit="0" offset="0"> >> <query> >> *:* AND oc_organization:mh_default_org AND >> *(oc_acl_read:ROLE_ANONYMOUS) >> *AND oc_mediatype:AudioVisual AND -oc_deleted:[* TO *] >> </query> >> </ns2:search-results> > > > , where, again, our user is not authenticated, but the system uses the > anonymous role instead. > > We have tried to establish a session, as it could be done in earlier > versions, but I clearly remember that this capability is no longer > supported and now all the requests have to be authenticated. And indeed > this no longer works in 1.3. > > We don't know if we are missing something or if this behaviour is > intended. Can anybody shed some light on why this is happening? > > Best regards > 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] _______________________________________________
