I finally thought about this a bit more, and yes this will be simpler for me (no need to have a relation with SecurityGroup), but
then I would have to add more than 1 field to SecurityGroupPermission.
I would need to add fields for
* view-name (or did I miss something); because this must done view by view not only for all views of a component. BTW shoud we not
remove the <!-- Tax Rate security --> block in ProductSecurityData.xml (if no answers I will remove insome days) ? I guess I forgot
it when I removed old tax fields in edit Store view.
* maxHit = number of hit before tarpitting the view for the login
* maxHitDuration = period of time associated with maxHit
* tarpitDuration = period of time the login will not be able to acces this
view again
For the moment I will create a ProtectedView entity, listable and editable from a Party/Security/4th menu I'm adding (from ftl
tabbar to xml), with the fields above + a field groupId (primay Key) in relations with SecurityGroup entity. No needs to
specifically define permissions for this feature. But of course to be able to have access to a view the user should have the right
permissions. It's another security level, not really security because few leaks may appear, but statistically the view will
protected.
Note that the mechanism I propose is used at the lower level (in request-map, by default you will only need to add
protected-view=true to protect a view from data leackage). You don't need to edit your screen, use if-has-permission, fail-widget,
etc.
Thanks
Jacques
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
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
