[jira] Reopened: (OFBIZ-2068) Patch for applications/accounting/config/AccountingEntityLabels.xml (language order)
[ https://issues.apache.org/jira/browse/OFBIZ-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reopened OFBIZ-2068: Assignee: Jacques Le Roux (was: Christian Geisert) Reopened to consider sort_langvalues.groovy integration as part of the Labels Manager Patch for applications/accounting/config/AccountingEntityLabels.xml (language order) Key: OFBIZ-2068 URL: https://issues.apache.org/jira/browse/OFBIZ-2068 Project: OFBiz Issue Type: Improvement Components: accounting Affects Versions: SVN trunk Reporter: Erik Wegner Assignee: Jacques Le Roux Priority: Trivial Fix For: SVN trunk Attachments: AccountingUiLabels.diff, sort_langvalues.groovy This patch file sorts the value entries in the file applications/accounting/config/AccountingEntityLabels.xml for each property in alphabetic order. Additionally it fixes some lines, where the nl-translation was inserted with the key »en«. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Discussion: Permissions Checking Enhancement
BJ, Yes there are plenty of options to improve and enhance security of login methods but they can still be stolen/copied/lost etc with varying degrees of ease and success. When that happens you're exposed to data leakage. The point of the feature is to limit that damage should a valid access method be compromised. For example if you have 10's of thousands of clients the reality is no one user would likely access more than N clients a day for normal work purposes, the number depending on the role of the user. Armed with that knowledge you can limit the access per day to a maximum number, should it be reached it can be reported, investigated and dealt with. Ray BJ Freeman wrote: sorry I have not responded till now Inline: Jacques Le Roux sent the following on 12/9/2008 7:37 AM: From: Jacques Le Roux [EMAIL PROTECTED] BJ, The client concern is in case a login/pwd couple is used but not by the right person (lost, stolen, etc.). Only biometric security could deal with that I guess. have to think on this one. using encrypted USB devices for login works with PGP. By limiting the number of time a page can be visited in a period of time you don't really prevent using UI to pull out confidential data but you make it so long (years) that it's not usable. It's something used in spam fighting known as tarpitting. It has proven to be very efficient and is now used in the gray list concept wich works great. Anyway for the moment it's the requirement I have BTW I wonder if it should not better block the account and send a message to the admin in such case. He/she would then be able to reset the login/pwd to secure anew the login. yes use tarpitting works very well. I found it really slows down the spammers. However if there is a heavy use of tarpitting, you are using up a lot of threads and memory. I think blocking the account, and sending a email to the person's registered email with a link back to the login would validate them. the link would let them validate the email then another email would send them their logging information. CC the Admin would be an option as well. I will put the check in at end of RequestHandler.renderView just after the block where ServerHitBin.countView is used. This would clearly separate this new security aspect. And having it at the framework level is clearly easier : you only have to define a list of pages to constrain by PartyRoles. have to review code before I comment. I had a better idea : to use a preprocessor event. I will though need to make a small change to allow to return a specific message from the event. I guess it will be the only thing I will commit, except if some people are interested in the tarpitting feature. interested but not knowledgeable enough to understand how it works. Jacques In the check I will need . PartyRole(s), . The list of pages to constrain access by PartyRoles. I will be an ConstrainViewByRole entity with 2 fields : partyRole viewName (pages are actually views in OFBiz) . Max number of page access allowed, and the period of time for counting the number of page accesses in security.properties . An AccessedPage entity with fields loginId viewAccessed dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) I think it's a feature generic enough to be used in Framework if someone is interested in future (if nothing is defined in security.properties the block would be simply skipped so it's harmful). So if nobody see a problem with that I will implement and commit. Any comments welcome Thanks Jacques
[jira] Closed: (OFBIZ-1935) Allow multi-pagination in a page
[ https://issues.apache.org/jira/browse/OFBIZ-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-1935. -- Resolution: Fixed Fix Version/s: SVN trunk Thanks Bilgin, Your (slightly modifiedf) patch is in trunk revision: 725053 . It's cool to be able to get back to page position using paginate-target-anchor and corresponding form name. I quickly look to see if something like that also exists for forms like EditCarrierAccount (with no pagination) but did not find anything. It would be cool to come back to the place where you made a change instead of top of page. So we might consider introduce an anchor attribute except it already exists and I missed it. Allow multi-pagination in a page --- Key: OFBIZ-1935 URL: https://issues.apache.org/jira/browse/OFBIZ-1935 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Jacques Le Roux Assignee: Bilgin Ibryam Fix For: SVN trunk Attachments: 1935.diff, 1935.diff If a page has more than one paginations (fe : view profile has one in Financial Account Summary and one in Shipper Account ) the pagination numbers become wrong, as both paginations use VIEW_SIZE and VIEW_INDEX parameters from the request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2074) Tarpitting feature for confidential data access
Tarpitting feature for confidential data access --- Key: OFBIZ-2074 URL: https://issues.apache.org/jira/browse/OFBIZ-2074 Project: OFBiz Issue Type: New Feature Components: ALL COMPONENTS Affects Versions: SVN trunk Environment: NA Reporter: Jacques Le Roux Assignee: Jacques Le Roux Priority: Minor The goal is to avoid, as much as possible, confidential data leakage. This feature will disallow access for a period of time to a view if this view is accessed more than a number of time in a period of time. This will prevent confidential data thievery done from a compromised login/pwd couple. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2074) Tarpitting feature for confidential data access
[ https://issues.apache.org/jira/browse/OFBIZ-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-2074: --- Remaining Estimate: 20h (was: 48h) Original Estimate: 20h (was: 48h) Tarpitting feature for confidential data access --- Key: OFBIZ-2074 URL: https://issues.apache.org/jira/browse/OFBIZ-2074 Project: OFBiz Issue Type: New Feature Components: ALL COMPONENTS Affects Versions: SVN trunk Environment: NA Reporter: Jacques Le Roux Assignee: Jacques Le Roux Priority: Minor Attachments: requesthandler.patch Original Estimate: 20h Remaining Estimate: 20h The goal is to avoid, as much as possible, confidential data leakage. This feature will disallow access for a period of time to a view if this view is accessed more than a number of time in a period of time. This will prevent confidential data thievery done from a compromised login/pwd couple. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1935) Allow multi-pagination in a page
[ https://issues.apache.org/jira/browse/OFBIZ-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655167#action_12655167 ] Jacques Le Roux commented on OFBIZ-1935: Thanks for the tip Bilgin Allow multi-pagination in a page --- Key: OFBIZ-1935 URL: https://issues.apache.org/jira/browse/OFBIZ-1935 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Jacques Le Roux Assignee: Bilgin Ibryam Attachments: 1935.diff, 1935.diff If a page has more than one paginations (fe : view profile has one in Financial Account Summary and one in Shipper Account ) the pagination numbers become wrong, as both paginations use VIEW_SIZE and VIEW_INDEX parameters from the request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Discussion: Permissions Checking Enhancement
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 = 36 (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 From: Jacques Le Roux [EMAIL PROTECTED] From: BJ Freeman [EMAIL PROTECTED] sorry I have not responded till now Inline: Thanks for your interest Jacques Le Roux sent the following on 12/9/2008 7:37 AM: From: Jacques Le Roux [EMAIL PROTECTED] BJ, The client concern is in case a login/pwd couple is used but not by the right person (lost, stolen, etc.). Only biometric security could deal with that I guess. have to think on this one. using encrypted USB devices for login works with PGP. I did not think about that. Anyway it's not the thing the client is looking for (too much turnover I imagine) By limiting the number of time a page can be visited in a period of time you don't really prevent using UI to pull out confidential data but you make it so long (years) that it's not usable. It's something used in spam fighting known as tarpitting. It has proven to be very efficient and is now used in the gray list concept wich works great. Anyway for the moment it's the requirement I have BTW I wonder if it should not better block the account and send a message to the admin in such case. He/she would then be able to reset the login/pwd to secure anew the login. yes use tarpitting works very well. I found it really slows down the spammers. However if there is a heavy use of tarpitting, you are using up a lot of threads and memory. I think blocking the account, and sending a email to the person's registered email with a link back to the login would validate them. the link would let them validate the email then another email would send them their logging information. CC the Admin would be an option as well. Actually we have also to deal with the rare case of an authorised person who reachs the limit. So we will redirect this person to an explicit screen where will ask him/her to request the admin him/herself. Thieves will be tarpitted, that's all. I will put the check in at end of RequestHandler.renderView just after the block where ServerHitBin.countView is used. This would clearly separate this new security aspect. And having it at the framework level is clearly easier : you only have to define a list of pages to constrain by PartyRoles. have to review code before I comment. Forget it : obsolete I had a better idea : to use a preprocessor event. I will though need to make a small change to allow to return a specific message from the event. I guess it will be the only thing I will commit, except if some people are interested in the tarpitting feature. interested but not knowledgeable enough to understand how it works. Really simple, I will create a Jira with a patch and hopefully a 3 lines explanation. It's much simpler and clean. So much things are already there, you just have to be patient enough to discover them at the rigth place, the right moment ;o) Jacques Jacques In the check I will need . PartyRole(s), . The list of pages to constrain access by PartyRoles. I will be an ConstrainViewByRole entity with 2 fields : partyRole viewName (pages are actually views in OFBiz) . Max number of page access allowed, and the period of time for counting the number of page accesses in security.properties . An AccessedPage entity with fields loginId viewAccessed dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed) I think it's a feature generic enough to be used in Framework if someone is interested in future (if nothing is defined in security.properties the block would be simply skipped so it's harmful). So if nobody see a problem with that I will implement and commit. Any comments welcome Thanks Jacques From: BJ Freeman [EMAIL PROTECTED] Jacques: my first
detecting timeout in service
Hello, can somebody tell me what is done the timeout is over when I do a runSync(myService) in Java ? Can you give me a message or trace sample ? Thanks a lot.
Re: Discussion: Permissions Checking Enhancement
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 = 36 (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 From: Jacques Le Roux [EMAIL PROTECTED] From: BJ Freeman [EMAIL PROTECTED] sorry I have not responded till now Inline: Thanks for your interest Jacques Le Roux sent the following on 12/9/2008 7:37 AM: From: Jacques Le Roux [EMAIL PROTECTED] BJ, The client concern is in case a login/pwd couple is used but not by the right person (lost, stolen, etc.). Only biometric security could deal with that I guess. have to think on this one. using encrypted USB devices for login works with PGP. I did not think about that. Anyway it's not the thing the client is looking for (too much turnover I imagine) By limiting the number of time a page can be visited in a period of time you don't really prevent using UI to pull out confidential data but you make it so long (years) that it's not usable. It's something used in spam fighting known as tarpitting. It has proven to be very efficient and is now used in the gray list concept wich works great. Anyway for the moment it's the requirement I have BTW I wonder if it should not better block the account and send a message to the admin in such case. He/she would then be able to reset the login/pwd to secure anew the login. yes use tarpitting works very well. I found it really slows down the spammers. However if there is a heavy use of tarpitting, you are using up a lot of threads and memory. I think blocking the account, and sending a email to the person's registered email with a link back to the login would validate them. the link would let them validate the email then another email would send them their logging information. CC the Admin would be an option as well. Actually we have also to deal with the rare case of an authorised person who reachs the limit. So we will redirect this person to an explicit screen where will ask him/her to request the admin him/ herself. Thieves will be tarpitted, that's all. I will put the check in at end of RequestHandler.renderView just after the block where ServerHitBin.countView is used. This would clearly separate this new security aspect. And having it at the framework level is clearly easier : you only have to define a list of pages to constrain by PartyRoles. have to review code before I comment. Forget it : obsolete I had a better idea : to use a preprocessor event. I will though need to make a small change to allow to return a specific message from the event. I guess it will be the only thing I will commit, except if some people are interested in the tarpitting feature. interested but not knowledgeable enough to understand how it works. Really simple, I will create a Jira with a patch and hopefully a 3 lines explanation. It's much simpler and clean. So much things are already there, you just have to be patient enough to discover them at the rigth place, the right moment ;o) Jacques Jacques In the check I will need . PartyRole(s), . The list of pages to constrain access by PartyRoles. I will be an ConstrainViewByRole entity with 2 fields : partyRole viewName (pages are actually views in OFBiz) . Max number of page access allowed, and the period of time for counting the number of page accesses in security.properties . An
Re: svn commit: r725466 - in /ofbiz/trunk/applications: accounting/config/ content/config/ party/config/ product/config/
[EMAIL PROTECTED] wrote: Author: mrisaliti Date: Wed Dec 10 14:18:58 2008 New Revision: 725466 URL: http://svn.apache.org/viewvc?rev=725466view=rev Log: Some wrong locales or duplicated locales while testing the new Label Manager. Modified: ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml ofbiz/trunk/applications/content/config/ContentErrorUiLabels.xml ofbiz/trunk/applications/content/config/ContentUiLabels.xml ofbiz/trunk/applications/party/config/PartyEntityLabels.xml ofbiz/trunk/applications/party/config/PartyUiLabels.xml ofbiz/trunk/applications/product/config/ProductEntityLabels.xml ofbiz/trunk/applications/product/config/ProductUiLabels.xml Modified: ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml?rev=725466r1=725465r2=725466view=diff == --- ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml (original) +++ ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml Wed Dec 10 14:18:58 2008 @@ -30,8 +30,8 @@ value xml:lang=nlBankrekening: AHC/Electronic Check /value value xml:lang=roCont EFT : AHC/Cecuri Electronice/value value xml:lang=ruТекÑÑий ÑÑеÑ/value -value xml:lang=thà¸à¸±à¸à¸à¸µà¸à¸à¸²à¸à¸²à¸£: AHC/à¸à¸£à¸§à¸à¸ªà¸à¸à¸£à¸°à¸à¸à¸à¸´à¹à¸¥à¹à¸à¸à¸£à¸à¸à¸´à¸à¸ªà¹/value value xml:lang=zhçµåèµé转账账æ·ï¼éèæºæå§åä¼/çµåæ¯ç¥¨/value +value xml:lang=thà¸à¸±à¸à¸à¸µà¸à¸à¸²à¸à¸²à¸£: AHC/à¸à¸£à¸§à¸à¸ªà¸à¸à¸£à¸°à¸à¸à¸à¸´à¹à¸¥à¹à¸à¸à¸£à¸à¸à¸´à¸à¸ªà¹/value /property property key=AccountingAccount value xml:lang=arØساب/value @@ -126,8 +126,8 @@ value xml:lang=escuentas/value value xml:lang=frComptes/value value xml:lang=itConti/value -value xml:lang=nlRekeningen/value value xml:lang=roConturi/value +value xml:lang=nlRekeningen/value value xml:lang=ruСÑеÑа/value value xml:lang=thà¸à¸±à¸à¸à¸µ/value value xml:lang=zhè´¦æ·/value These are 2 examples, that I believe are wrong. You've changed the case ordering of the labels; I noticed other cases in this commit where you did the same. Please fix the order. Plus, in at least these 2 cases, you didn't actually change anything. Please don't do several things in one commit. If there are duplicates, fine, remove them. If you need to change the order, do that in a separate commit.
Re: svn commit: r725466 - in /ofbiz/trunk/applications: accounting/config/ content/config/ party/config/ product/config/
Thanks a lot Adam to advice me I have fixed into rev. 725477. It was due to a conflict I had in my local build before commit. Marco Il giorno 10/dic/08, alle ore 23:22, Adam Heath ha scritto: [EMAIL PROTECTED] wrote: Author: mrisaliti Date: Wed Dec 10 14:18:58 2008 New Revision: 725466 URL: http://svn.apache.org/viewvc?rev=725466view=rev Log: Some wrong locales or duplicated locales while testing the new Label Manager. Modified: ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml ofbiz/trunk/applications/content/config/ContentErrorUiLabels.xml ofbiz/trunk/applications/content/config/ContentUiLabels.xml ofbiz/trunk/applications/party/config/PartyEntityLabels.xml ofbiz/trunk/applications/party/config/PartyUiLabels.xml ofbiz/trunk/applications/product/config/ProductEntityLabels.xml ofbiz/trunk/applications/product/config/ProductUiLabels.xml Modified: ofbiz/trunk/applications/accounting/config/ AccountingUiLabels.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml?rev=725466r1=725465r2=725466view=diff = = = = = = = = = = --- ofbiz/trunk/applications/accounting/config/ AccountingUiLabels.xml (original) +++ ofbiz/trunk/applications/accounting/config/ AccountingUiLabels.xml Wed Dec 10 14:18:58 2008 @@ -30,8 +30,8 @@ value xml:lang=nlBankrekening: AHC/Electronic Check / value value xml:lang=roCont EFT : AHC/Cecuri Electronice/ value value xml:lang=ruТекÑÑий ÑÑеÑ/value -value xml:lang=thà¸à¸±à¸à¸à¸µà¸à¸à¸²à¸à¸²à¸£: AHC/à¸à¸£à¸§à¸à¸ªà¸ à¸à¸£à¸°à¸à¸à¸ ิà¹à¸¥à¹à¸à¸à¸£à¸ à¸à¸´à¸à¸ªà¹/value value xml:lang=zhçµå èµéè½¬è´¦è ´¦æ·ï¼éèæºæå§åä¼/çµå æ¯ç¥¨/value +value xml:lang=thà¸à¸±à¸à¸à¸µà¸à¸à¸²à¸à¸²à¸£: AHC/à¸à¸£à¸§à¸à¸ªà¸ à¸à¸£à¸°à¸à¸à¸ ิà¹à¸¥à¹à¸à¸à¸£à¸ à¸à¸´à¸à¸ªà¹/value /property property key=AccountingAccount value xml:lang=arØ Ø³Ø§Ø¨/value @@ -126,8 +126,8 @@ value xml:lang=escuentas/value value xml:lang=frComptes/value value xml:lang=itConti/value -value xml:lang=nlRekeningen/value value xml:lang=roConturi/value +value xml:lang=nlRekeningen/value value xml:lang=ruСÑеÑа/value value xml:lang=thà¸à¸±à¸à¸à¸µ/value value xml:lang=zhè´¦æ·/value These are 2 examples, that I believe are wrong. You've changed the case ordering of the labels; I noticed other cases in this commit where you did the same. Please fix the order. Plus, in at least these 2 cases, you didn't actually change anything. Please don't do several things in one commit. If there are duplicates, fine, remove them. If you need to change the order, do that in a separate commit.
[jira] Updated: (OFBIZ-2070) New tool to get labels information
[ https://issues.apache.org/jira/browse/OFBIZ-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Risaliti updated OFBIZ-2070: -- Attachment: LabelsInfo4.patch I have done some changes but still not been completed, please do not commit it's only if someone want to review it. Thanks Marco New tool to get labels information -- Key: OFBIZ-2070 URL: https://issues.apache.org/jira/browse/OFBIZ-2070 Project: OFBiz Issue Type: New Feature Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Marco Risaliti Priority: Minor Fix For: SVN trunk Attachments: LabelsInfo3.patch, LabelsInfo4.patch, LabesInfo_screenshot.png New tool to get labels information used in OFBiz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Discussion: Permissions Checking Enhancement
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 = 36 (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
Re: detecting timeout in service
Please Fabien, remember this kind of question should be on user ML (you will not get much answers here) From: Fabien JALABERT [EMAIL PROTECTED] Hello, can somebody tell me what is done the timeout is over when I do a runSync(myService) in Java ? Can you give me a message or trace sample ? Not sure to well understand the question. But I guess the answer is : unless you use use-transaction=false and there is not alredy a running transaction, each service is done in a transaction and in such case (time-out) the surrounding transaction is simply rolled back Note that you can specify a transaction-timeout in seconds (defaults to 60) but it only works when a new transaction is started. By default, you can have a new transaction if there is not already a running transaction (in this case the service engine create a new transation for you by default, unless you use use-transaction=false) or if you set require-new-transaction to true. In latter case the new transaction can be embedded in an existing transaction. A roll-back on the new transaction will also roll-back the surrounding transaction or all (2 transactions) is commited, if it's ok. HTH Jacques Thanks a lot.
