From: "David E Jones" <david.jo...@hotwaxmedia.com>
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...
I suppose you meaned "with the limit of hits per time period ".
I'm not sure this would allow the other requirements we have :
1) redirect to an explaining page (directions to ask admin, etc.), being error response,
blanck (":none") or a general default as I
suggested recently;
2) allow the admin to reset the tarpitted (greyed or grayed ) login in case of
false protection (false protection being a person
needed really to do as much hits, without any security information compromised)
3) keep traces of the abuse
4) Ray ?
Also I'm pretty advanced now and it fits well in the architecture, pre-processing is relevant for this case I guess... The only
drawback being this ugly code (harcoded method name) I have still in RequestHandler.doRequest() if I want to optimise pre-processing
Thanks
Jacques
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