Marius Petria wrote > Hi, > > Do we need an additional interface to check for user existence, or could we > just treat it as a special case of validity by using the ServiceUserValidator? >
I think it's easier :) We can just try to login to the resource resolver factory. If it fails, there is something wrong. If it works, the service user exists (in all providers) Carsten > Marius > > On 5/12/17, 7:14 PM, "Carsten Ziegeler" <[email protected]> wrote: > > Julian Sedding wrote > > > > > Interesting aspect that "all" need to have the service user. I had > > assumed "at least one" resource provider needs to have the service > > user. > > > > Both "all" and "at least one" are heuristics, because we don't know > > what the service-user will access. > > Not exactly :) At least all providers which require authentication and > are not lazy need to provide this service user. Otherwise the login > already fails. > > > > > In some cases "all" may be too strict: you need to provide matching > > users in all RRPs to allow a service user access to one of them. > > In other cases "at least one" may be to lax: the service user actually > > needs to access multiple RRPs. > > > > Not sure where the sweet spot is... Maybe we should allow indicating > > the desired RRP(s) in the ServiceUserMapped's target filter (which can > > be set via configuration, i.e. during deployment). > > I think we should not break the abstraction by doing so. If we go with > the requirement that all non lazy providers must have this, then I think > we are pretty close to what is usually needed. As mentioned of a non > lazy provider does not have the service user, the login will fail > anyways. So the only option we have is whether to check the existence > with lazy providers as well. I think we should not check for this is > exactly what the difference between lazy and non lazy resource providers > is intended for. > > Regards > > Carsten > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
