Why not keep it super-simple at just add a field to the
SecurityGroupPermission entity with the limit of times per time period
that a user in that group can access that permission. Then in the low-
level permission checking code keep a count...
That would probably total less than 100 lines of changes (unless you
got really fancy).
-David
On Dec 11, 2008, at 11:25 PM, Jacques Le Roux wrote:
As you may seen in the last patch I updloaded in https://issues.apache.org/jira/browse/OFBIZ-2074
I use a standard preprocesor to deal with the protect-view feature.
In concerned request-maps, error responses should be associated with
each protected views. This has advantages and drawbacks
Advantages : it's flexible, you can define the view you want, if you
define none, a blanck page is rendered (using ":none")
Drawbacks : they are 2 parts to protect a view. You must define the
view to protect from Party/Security in a (definitive name ;o)
ProtectedView entity (was ConstrainviewByRole before) *and* set an
error response in the corresponding request-map. Not a clear
process, if you forgot the error response a protective blank page is
rendered but without any information in case of false tarpitting.
I think now we could provide a default error response view for all
request-map. I guess most of the time this view will be used instead
of a specific one. It could then favourably replace the blank
rendered page.
Thanks
Jacques
