[jira] [Commented] (OFBIZ-10307) Navigate from a domain to another with automated signed in authentication
[ https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646735#comment-16646735 ] Michael Brohl commented on OFBIZ-10307: --- Thanks for reporting this, Jacques. That's why it is always a good idea to allow some time for review... > Navigate from a domain to another with automated signed in authentication > - > > Key: OFBIZ-10307 > URL: https://issues.apache.org/jira/browse/OFBIZ-10307 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > Attachments: OFBIZ-10307-test from example.patch, OFBIZ-10307-test > from example.patch, OFBIZ-10307-test from example.patch, > OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, > OFBIZ-10307-test.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch > > > This will use a JWT Token authentication to get from one domain, where you > are signed in, to another domain where you get signed in automatically. > Something like ExternalLoginKey or Tomcat SSO, but not on the same domain. > This will build upon the initial work done at OFBIZ-9833 which has been > partially reverted in trunk with r1827439 (see OFBIZ-10304) and r1827441. I > explained why and what I did at [https://s.apache.org/a5Km] > I turned to Ajax for the "Authorization" header sending. I initially thought > I'd just pass an "Authorization" header and use it in the > externalServerLoginCheck preprocessor, et voilà. > But I stumbled upon something I did not know well : CORS! And in particular > the upstream control (Pre-verified requests): > > [https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Preflight_example] > [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS] > [https://www.w3.org/TR/cors/] > To be able to pass an "Authorization" header, the server must respond > positively in the Preflight HTTP response (OPTIONS). To do this, either you > use a Tomcat filter (or your own filter, there are examples on the Net) or > use HTTPD (or Nginx) configuration on the target server. > I tried Tomcat first, without success. With HTTPD it's easier just 3 lines. > For my tests, future tests by OFBiz users and as an example, I asked infra to > put them in our HTTPD trunk demo config: > Header set Access-Control-Allow-Origin "https://localhost:8443; > Header set Access-Control-Allow-Headers "Authorization" > Header set Access-Control-Allow-Credentials "true" > No code change (either in all web.xml files for Tomcat or Java for own > filter), and more safety. It does not give more right to outsiders than what > we give with the admin credential. > In Header set Access-Control-Allow-Origin you can put more domains. I just > used [https://localhost:8443|https://localhost:8443/] for the tests. > It works in Chrome, Firefox and Opera and partially in IE11 (not tested in > Edge). I did not test Safari, but I guess like other modern browsers it > should work. > For those (very few I guess) interested by IE11 (for Edge test yourself and > report please), here is the solution > > [https://stackoverflow.com/questions/12643960/internet-explorer-10-is-ignoring-xmlhttprequest-xhr-withcredentials-true] > > [https://web.archive.org/web/20130308142134/http://msdn.microsoft.com/en-us/library/ms537343%28v=vs.85%29.aspx] > > [https://blogs.msdn.microsoft.com/ieinternals/2013/09/17/a-quick-look-at-p3p/] > TODO (maybe) in the future, use the new Fetch API (not available yet): > [https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API] > > Here is a complement about the way it's architectured: > # A change to cookies was introduced with OFBIZ-4959. Actually it was not > really a bug rather a clean-up. The autoLogin cookies were only used by the > ecommerce component and maybe webpos. But all applications were creating such > cookies with a one year duration. They were useless until I needed them for > the feature of this Jira issue. But even if they were safe (httponly) then I > needed them to be clean, not a one year duration (to be as safe as possible, > temporary cookies are better). So after doing it crudely, [inspired by > Taher's suggestion|[https://s.apache.org/qLGC]] I introduced the > keep-autologin-cookie attribute in ofbiz-component.xml. It's used to > remove not kept cookies when login in or out. So those cookies are only kept > during a session. Also a cookie is created when an user jumps from one > application to another on the source domain. These cookies are used when
[jira] [Commented] (OFBIZ-10307) Navigate from a domain to another with automated signed in authentication
[ https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646636#comment-16646636 ] Jacques Le Roux commented on OFBIZ-10307: - While working on the documentation I found a flaw in my architecture. I'll soon provide a new patch with the fix. > Navigate from a domain to another with automated signed in authentication > - > > Key: OFBIZ-10307 > URL: https://issues.apache.org/jira/browse/OFBIZ-10307 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > Attachments: OFBIZ-10307-test from example.patch, OFBIZ-10307-test > from example.patch, OFBIZ-10307-test from example.patch, > OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, OFBIZ-10307-test.patch, > OFBIZ-10307-test.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch, > OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch > > > This will use a JWT Token authentication to get from one domain, where you > are signed in, to another domain where you get signed in automatically. > Something like ExternalLoginKey or Tomcat SSO, but not on the same domain. > This will build upon the initial work done at OFBIZ-9833 which has been > partially reverted in trunk with r1827439 (see OFBIZ-10304) and r1827441. I > explained why and what I did at [https://s.apache.org/a5Km] > I turned to Ajax for the "Authorization" header sending. I initially thought > I'd just pass an "Authorization" header and use it in the > externalServerLoginCheck preprocessor, et voilà. > But I stumbled upon something I did not know well : CORS! And in particular > the upstream control (Pre-verified requests): > > [https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Preflight_example] > [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS] > [https://www.w3.org/TR/cors/] > To be able to pass an "Authorization" header, the server must respond > positively in the Preflight HTTP response (OPTIONS). To do this, either you > use a Tomcat filter (or your own filter, there are examples on the Net) or > use HTTPD (or Nginx) configuration on the target server. > I tried Tomcat first, without success. With HTTPD it's easier just 3 lines. > For my tests, future tests by OFBiz users and as an example, I asked infra to > put them in our HTTPD trunk demo config: > Header set Access-Control-Allow-Origin "https://localhost:8443; > Header set Access-Control-Allow-Headers "Authorization" > Header set Access-Control-Allow-Credentials "true" > No code change (either in all web.xml files for Tomcat or Java for own > filter), and more safety. It does not give more right to outsiders than what > we give with the admin credential. > In Header set Access-Control-Allow-Origin you can put more domains. I just > used [https://localhost:8443|https://localhost:8443/] for the tests. > It works in Chrome, Firefox and Opera and partially in IE11 (not tested in > Edge). I did not test Safari, but I guess like other modern browsers it > should work. > For those (very few I guess) interested by IE11 (for Edge test yourself and > report please), here is the solution > > [https://stackoverflow.com/questions/12643960/internet-explorer-10-is-ignoring-xmlhttprequest-xhr-withcredentials-true] > > [https://web.archive.org/web/20130308142134/http://msdn.microsoft.com/en-us/library/ms537343%28v=vs.85%29.aspx] > > [https://blogs.msdn.microsoft.com/ieinternals/2013/09/17/a-quick-look-at-p3p/] > TODO (maybe) in the future, use the new Fetch API (not available yet): > [https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API] > > Here is a complement about the way it's architectured: > # A change to cookies was introduced with OFBIZ-4959. Actually it was not > really a bug rather a clean-up. The autoLogin cookies were only used by the > ecommerce component and maybe webpos. But all applications were creating such > cookies with a one year duration. They were useless until I needed them for > the feature of this Jira issue. But even if they were safe (httponly) then I > needed them to be clean, not a one year duration (to be as safe as possible, > temporary cookies are better). So after doing it crudely, [inspired by > Taher's suggestion|[https://s.apache.org/qLGC]] I introduced the > keep-autologin-cookie attribute in ofbiz-component.xml. It's used to > remove not kept cookies when login in or out. So those cookies are only kept > during a session. Also a cookie is created when an user jumps from one > application to another on the source domain. These cookies
[jira] [Commented] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646175#comment-16646175 ] Nicolas Malin commented on OFBIZ-4361: -- Sorry for the delay, I started Dennis's patch review unfortunately, I was saturated by a customer project and this patch need many attention :). I hope to review it on Novembre, thanks for your patience ! > Any ecommerce user has the ability to reset anothers password (including > admin) via "Forget Your Password" > -- > > Key: OFBIZ-4361 > URL: https://issues.apache.org/jira/browse/OFBIZ-4361 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 11.04, Release Branch 13.07, Release > Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release > Branch 17.12 > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl >Priority: Major > Labels: security > Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch, > OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch, > OFBIZ-4361_Token-Password-Registration.patch > > > Currently, any user (via ecommerce "Forget Your Password") has the ability to > reset another users password, including "admin" without permission. By > simply entering "admin" and clicking "Email Password", the following is > displayed. > The following occurred: > A new password has been created and sent to you. Please check your Email. > This now forces the user of the ERP to change their password. It is also > possible to generate a dictionary attack against ofbiz because there is no > capta code required. This is serious security risk. > This feature could be reduced to a certain sub-set of users, whose login name > is optionally in the format of an email address, and maybe require a capta > code to prevent dictionary attacks. > For example, limit the feature to role "Customer" of type "Person" which was > generated via an ecommerce transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10600) Change the Menu extends-resource management to allow structure changes by themes
[ https://issues.apache.org/jira/browse/OFBIZ-10600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien NICOLAS updated OFBIZ-10600: --- Attachment: OFBIZ-10600.patch > Change the Menu extends-resource management to allow structure changes by > themes > > > Key: OFBIZ-10600 > URL: https://issues.apache.org/jira/browse/OFBIZ-10600 > Project: OFBiz > Issue Type: Improvement > Components: themes >Affects Versions: Trunk >Reporter: Julien NICOLAS >Assignee: Julien NICOLAS >Priority: Minor > Fix For: Upcoming Branch > > Attachments: OFBIZ-10600.patch > > > Today it's impossible to change menu structure from the theme component. > I need to modify the structure only for my new theme but it's actually not > possible. > The coming soon patch will allow to do it by using more or less the same > setting than the actual screen override setting. > Menu theme customization will be more flexible :) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-7113) Refactoring permission model call
[ https://issues.apache.org/jira/browse/OFBIZ-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646121#comment-16646121 ] Nicolas Malin commented on OFBIZ-7113: -- Jacques, with this issue, I found some unit test that are bad and testIntegration failed if they aren't corrected. I will check for point 3 et 4 > Refactoring permission model call > - > > Key: OFBIZ-7113 > URL: https://issues.apache.org/jira/browse/OFBIZ-7113 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin >Priority: Minor > Attachments: OFBIZ-7113.patch, OFBIZ-7113.patch, OFBIZ-7113.patch > > > With the subject on mailing list "Permission service not on the same > transaction" : http://markmail.org/message/34vxi4ntmbj7vzcr > I started the improvement but the java code need to be clean and refactoring. > I share my first draft patch, but need more works. I realize : > * unified call evalPermission > * move all related field for permission service on ModelService to > ModelPermission > * Remove deprecated code > * start labelized error message > * add new attributes on permission model : required-new-transaction and > return-error-on-failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
