That's what I suggested 1st, But Ray, who is the leader on this project, has
another opinion. So I will wait his answer...
I wondered also : but I finally think the name of the field viewName is not
ambiguous (can't really be confused with SQL view)
For managing this ConstrainViewBy... entity I think about adding a (ConstrainView?)
button in Party/Security after "New Security
Group" "Cert Issuers" buttons. It will lead to a find/list screen with edit and
remove buttons by lines. Edit button leading to and
edit screen available also on top of previous screen from a button (classical).
Note that if we use ConstrainViewBySecurityGroup we would rather add a (ConstrainView?)
button after "Security Groups Permissions"
"User Logins" buttons of the "Security Group" sub-menu (when you edit a
Security Group) leading also to the screens described above.
We need at least 2 other entities :
1) one to count hits on each view for each login monitored (login/view couple
actually)
. to be able to decide to tarpit a login on a view
. in case of blocking, an error reponse view will be used to give directions
(ask the admin, etc.) to any user tarpitted by
error (values to be adjusted in ConstrainViewBy... entity certainly).
. I have still to write a smal change to deal whith the
"no-error-response-provided" case to avoid showing the success view (a
none view - ie blanck view - will be shown then)
2) another to store logins/views tarpitted
. to quickly prevent any new access to tarpitted views
. to allow admin to reset them on demand (maybe with an UI, maybe not)
1) We have 2 opposed constraints here : quickly compute hits while being
sufficiently accurate.
As this will be pre-processed for each monitored login/view couples we need to
pre-compute as much as possible. But this is a
dynamic system, whe don't have a fixed a period of time to count hit as it's
done for ServerHitBin for instance.
Fortunately, the maxHitDuration is normaly setted after some kind of
tuning/profiling (or maybe intially from application
knowledge). So we may choose this value as a revolving period of time to sum
hits (beginning the 1st period with the 1st hit). If it
proves to be too short (too much false tarpits) it will have to be adjusted,
that's all. Another time don't worry, in the OOTB
version we will provide sufficently large values on (an only on) an example
view.
The entity will be AccessedView with fields
. accessedViewName
. userLoginId
. numberOf Hits = number of acces to the view by the login in the last
maxHitDuration
To avoid an SQL request to know which login/view couples we need to monitor
each time we pre-process a request we should have an
entity
ConstrainViewByUserLogin with fields
userLoginId = derived from Roles or Permission Groups
viewName = name of view to check for constraint
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
This entity will be updated on every change in UserLoginSecurityGroup and
ConstrainViewByRole (I did not think more yet but maybe
could be a view-entity)
2) TarpittedViewLogin with fields
. userLoginId
. viewName
. tarpitReleaseDateTime (0 meaning no tarpit, to allow the admin to free a
login/view)
For those interested, I have opened a Jira issue
https://issues.apache.org/jira/browse/OFBIZ-2074, not much in it yet, will be
completed progressively while discussing on this ML.
Sorry for the long post, thanks
Jacques
From: "David E Jones" <[EMAIL PROTECTED]>
Instead of attaching this to a Party RoleType, it would be better to attach it
to a SecurityPermission or SecurityGroup. Access
to resources like pages and such is governed by permissions in OFBiz, and
roles are used for record-level security (like which
parties a user can view/edit/etc as opposed to being able to use the view
profile screen).
-David
On Dec 10, 2008, at 3:54 AM, Jacques Le Roux wrote:
After a discussion with Ray I finally changed my mind and we would like to
commit more changes.
It will be an entity with demo data. Nobody will be harmed since we will put
large enough values on an example view.
Entity name :
ConstrainViewByRole, fields :
partyRole = a party role
viewName = name of view to check for constraint
maxHit = number of hit before tarpitting the view for the login
maxHitDuration = period of time associated with maxHit (no more than 1000 hits
in 3 mins, for instance)
tarpitDuration = period of time the login will not be able to acces this view
again
Example :
partyRole = consultant
view = confidentialDataView
maxHit = 1000
duration = 360 (seconds = 3 mins)
tarpitDuration = 360000 (seconds = 100 hours)
If a login with consultant role has more than 1000 hits in 6 mins on the
confidentialDataView it will be tarpitted for 100
heures
I will also commit the BlockingWorker used by the prepocessor event. I have
not written it yet but I suppose with at least 2
methods : one to count hits called by the main one which takes the decision
and send informations (return status, possible msg)
to the Controller (RequestHandler.doRequest)
Since nobody objected, I will soon open a Jira issue with a 1st patch version
with only the RequestHandler.doRequest changes for
now.
Thanks
Jacques
