Ben Alex wrote:
I would probably try to avoid doing the run-as replacement, as it is a
little challenging to overcome the issue you've described without
creating the user an entirely different way or exposing an internal
token used by AbstractSecurityInterceptor (which I would rather not do,
as
Brian Moseley wrote:
Brian Moseley wrote:
that sounds right. i don't have any need for access control on this
operation, so it looks like i can simply use anonymous authen and
then have my jackrabbit access manager use an
AuthenticationTrustResolver to see if the Authentication is
anonymous. i
Brian Moseley wrote:
that sounds right. i don't have any need for access control on this
operation, so it looks like i can simply use anonymous authen and then
have my jackrabbit access manager use an AuthenticationTrustResolver to
see if the Authentication is anonymous. i think that will work.
Ben Alex wrote:
I think your use case would be better suited to the anonymous
authentication capability. It is especially designed for giving an
unauthenticated request an Authentication, and the
SecurityEnforcementFilter recognises the fact it is an anonymous
Authentication and will redirect t
Brian Moseley wrote:
it seems like the runas facilities might be able to give me what i want.
is there a way to set up acegi security so that the http request itself
is not authenticated but runas is used specifically only for the
repository login?
Hi Brian
Run-as replacement is more often used to
i'm implementing an account signup operation in my dav server. part of
this process requires logging in to the server's jcr repository.
as discussed previously, the repository's login procedure requires acegi
security to have previously authenticated the request. this is true
every other time my se
