From a hackers point of view this would open up security hole.
Vinay Agarwal sent the following on 5/18/06 12:21 PM:
> Hello:
>
>
>
> I propose extension to the security API to allow for data-driven per-session
> or per-call authentication. This would meet my security needs ([OFBiz] Users
> - Security API: What am I missing?) and possibly of others.
>
>
>
> This scheme would add additional fields to userLogin entity which specify
> its permissions (a List) for the entities owned by a specific party
> (specified through partyId).
>
>
>
> Additions to userLogin: For temporary use only, not to be stored in db
>
> Authentications (Map) stores partyId (key) and List of permission Strings.
> As example,
>
> party1 perm11 perm12
>
> party2 perm2
>
> This would act as the userLogin as (perm11 + perm12) on party1's data and
> perm2 on party2's data.
>
>
>
> Additional function to Security interface:
>
> public abstract GenericValue authenticateAsParty(GenericValue userLoginTba,
> String partyId);
>
> Return result is a modified userLogin with additional security information
> if any. In the default implementation, simply returns the supplied
> userLogin. Alternately, it can be overwritten to provide additional security
> data in the return userLogin. This userLogin should not be stored in session
> so that the permissions can be controlled to per call level.
>
>
>
> Security check would check for these permissions after the existing
> permission check.
>
>
>
> Would this be of any use?
>
>
>
> Regards,
>
> Vinay Agarwal
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Locked
