Protect-view pre-processor

[Jacques Le Roux <ja...@les7arts.com>]

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

Re: Protect-view pre-processor

[Jacques Le Roux <ja...@les7arts.com>]

From: "David E Jones" <da...@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
>>
>

Re: Protect-view pre-processor

[David E Jones <da...@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...

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
>