I have submitted a last patch in
https://issues.apache.org/jira/browse/OFBIZ-2074. In this patch I left the
ProtectedViewAccessed
entity defintion but I will remove it as it not used. All is done in the
session, I guess it's enough for our need.
It's finally pretty simple to use.
You define the views you want to protect under a security group using the
protected view menu.
There you define the
* viewName using one uri atribute of in request-map element of the
controller.xml files
* Maximum number of visits (per period)
* Duration during which the visits are considered (in seconds)
* Duration during which the view will not be accessible (in seconds)
The last parameter defines the tarpitting period.
You don't have to define anything else for the protected views mechanism to work. If you
don't define a "protect" response, in case
of blocking the screen rendered will be blank by default. But you may define a generic
"protect" response view which will be
rendered by default using the default.error.response.view parameter in
security.properties.
The code use a simple strategy as we don't need something very sophisticated to
trap malignants. It's all in ProtectViewWorker.java.
Jacques
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
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
