[jira] [Commented] (OFBIZ-9833) Token Based Authentication
[
https://issues.apache.org/jira/browse/OFBIZ-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512622#comment-16512622
]
Jacques Le Roux commented on OFBIZ-9833:
OK, the work is now ready to be reviewed at OFBIZ-10307.
And BTW Jacopo, as I'm curious and read about it already elsewhere, I began to
read "Ulysses" by Joyce (in French for now). I better understand now what you
meant by stream-of-consciousness. Following advices on the net, I begin to read
the book by the end (last chapter, "Penelope"). Then stopped at the middle of
the chapter, and started again in the middle of the book. It's disturbing at
start, but I now like this idea of no real story. Though I must say the 2nd
chapter I'm reading in the middle ("Scylla and Charybdis", after
"Lestrygonians" that I liked) which is a bit about Shakespeare is even more
disconcerting than the 2 others before. This is really something new to me and
I must say interesting, thanks for the idea.
> Token Based Authentication
> --
>
> Key: OFBIZ-9833
> URL: https://issues.apache.org/jira/browse/OFBIZ-9833
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
>Priority: Major
> Attachments: JSON Web Tokens.pdf, OFBIZ-9833-JWTManager.patch, Token
> Based Authentication in Apache OfBiz.pdf, Token Based Authentication.pdf,
> rfc7519.pdf
>
>
> Here is dev list discussion for token based authentication work:
> http://markmail.org/message/vyskeh2wujqpkbwg
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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=16512591#comment-16512591 ] Jacques Le Roux commented on OFBIZ-10307: - All is ready now for review, I notably want to know if we are OK to have a link from an example localhost component to our trunk demo. There can be no problems with that because anyway it's only doing the same than signin in with an admin demo credential. I'll do this TODO once we agree about the work already done. bq. TODO use later Deepak's createJwt in OFBIZ-9833-JWTManager.patch after complete patch review and test. We will also need to discuss, but eventually, how to keep the ExternalServerJwtMasterSecretKey really secret. I think now things are simple enough for everybody to review, please do :) > 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.patch, OFBIZ-10307-test.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
[jira] [Updated] (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:all-tabpanel ] Jacques Le Roux updated OFBIZ-10307: Attachment: OFBIZ-10307.patch OFBIZ-10307-test from example.patch > 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.patch, OFBIZ-10307-test.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 > navigating from a domain to another to guarantee the safety of the user who > jumps from the source domain to the target domain. Note that protected > cookies (httponly) are one of the safer ways to store information, [js script > can't use >
[jira] [Commented] (OFBIZ-9283) Remove code dependencies from application (at least product) to plugins (at least ecommerce)
[
https://issues.apache.org/jira/browse/OFBIZ-9283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512568#comment-16512568
]
Jacques Le Roux commented on OFBIZ-9283:
I can confirm the dependency of framework to ecommerce in code, I already
created OFBIZ-9241 for that
> Remove code dependencies from application (at least product) to plugins (at
> least ecommerce)
>
>
> Key: OFBIZ-9283
> URL: https://issues.apache.org/jira/browse/OFBIZ-9283
> Project: OFBiz
> Issue Type: Sub-task
> Components: ecommerce, product
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Major
> Fix For: 17.12.01
>
>
> Some applications have still references in code to plugins. I think it's only
> product to ecommerce but could be more...
> I did not try but I guess if you use only the framework (w/o plugins) and try
> the link in the catalog/control/EditProduct screen which leads to ecommerce
> ("Product Page") you will get an error, so it's a bug!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10434) Common theme does not work when using a path with a space in
Jacques Le Roux created OFBIZ-10434:
---
Summary: Common theme does not work when using a path with a space
in
Key: OFBIZ-10434
URL: https://issues.apache.org/jira/browse/OFBIZ-10434
Project: OFBiz
Issue Type: Bug
Components: themes
Affects Versions: Trunk, 17.12.01
Reporter: Jacques Le Roux
On Windows a least, but I guess also on *nix OS, when I use a path with a space
in like {{C:\projectsASF\ofbiz-framework -Copie}} I get this error:
{code}
2018-06-14 16:40:51,623 |jsse-nio-8443-exec-3 |ControlServlet
|W| Communication error with the client while processing the request:
/catalog/control/login
org.apache.ofbiz.webapp.control.RequestHandlerException: Error in the response
writer/output stream: freemarker.template.TemplateNotFoundException: Template
not found for name "component://common-theme/templa
te/macro/HtmlScreenMacroLibrary.ftl".
The name was interpreted by this TemplateLoader: MultiTemplateLoader(loader1 =
org.apache.ofbiz.base.util.template.FreeMarkerWorker$FlexibleTemplateLoader@cde0d8,
loader2 = StringTemplateLoader(Map { })). (Te
mplate not found for name
"component://common-theme/template/macro/HtmlScreenMacroLibrary.ftl".
The name was interpreted by this TemplateLoader: MultiTemplateLoader(loader1 =
org.apache.ofbiz.base.util.template.FreeMarkerWorker$FlexibleTemplateLoader@cde0d8,
loader2 = StringTemplateLoader(Map { })).)
at
org.apache.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:1002)
~[ofbiz.jar:?]
at
org.apache.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:646)
~[ofbiz.jar:?]
at
org.apache.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213)
[ofbiz.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
[javax.servlet-api-4.0.0.jar:4.0.0]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
[javax.servlet-api-4.0.0.jar:4.0.0]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:191)
[ofbiz.jar:?]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:157)
[ofbiz.jar:?]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:494)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:651)
[tomcat-catalina-9.0.7.jar:9.0.7]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
[tomcat-catalina-9.0.7.jar:9.0.7]
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:407)
[tomcat-coyote-9.0.7.jar:9.0.7]
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
[tomcat-coyote-9.0.7.jar:9.0.7]
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:754)
[tomcat-coyote-9.0.7.jar:9.0.7]
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1376)
[tomcat-coyote-9.0.7.jar:9.0.7]
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
[tomcat-coyote-9.0.7.jar:9.0.7]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_112]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_112]
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
[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=16512552#comment-16512552 ] Jacques Le Roux commented on OFBIZ-10307: - All the work done previously (notably for OFBIZ-9833 and OFBIZ-1206) has been reverted at r1833510. I'm now able to provide a complete patch 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.patch, OFBIZ-10307-test.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 > navigating from a domain to another to guarantee the safety of the user who > jumps from the source domain to the target domain. Note that protected > cookies (httponly) are one of the safer ways to store information, [js script > can't use >
[jira] [Comment Edited] (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=16512469#comment-16512469
]
Jacques Le Roux edited comment on OFBIZ-10307 at 6/14/18 1:35 PM:
--
After the related blocking/prior issues have been fixed/done (mostly upgrading
to Tomcat 9), it's fully time to continue.
I'll soon revert the work done previously. And will submit a complete patch
here.
Testing with jleroux.nereide.fr is available for 2 months. Note that if you use
the Privacy badger Firefox addon you need to disable it for the localhost page
else it blocks the CORS call.
I propose we eventually demonstrate this feature from the example application.
So I'll add a very simple feature in example with a new {{OFBIZ-10307-test from
example.patch}}
WIP...
was (Author: jacques.le.roux):
I'll soon revert the work done previously. And will submit a complete patch
here.
Rahh, added too early, wrong key. I 'll edit...
> 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.patch, OFBIZ-10307-test.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
[jira] [Comment Edited] (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=16512469#comment-16512469 ] Jacques Le Roux edited comment on OFBIZ-10307 at 6/14/18 1:33 PM: -- I'll soon revert the work done previously. And will submit a complete patch here. Rahh, added too early, wrong key. I 'll edit... was (Author: jacques.le.roux): I'll soon revert the work done previously. And will submit a complete patch here. > 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.patch, OFBIZ-10307-test.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 > navigating from a domain to another to guarantee the safety of the user who > jumps from the source domain to the target
[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=16512469#comment-16512469 ] Jacques Le Roux commented on OFBIZ-10307: - I'll soon revert the work done previously. And will submit a complete patch here. > 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.patch, OFBIZ-10307-test.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 > navigating from a domain to another to guarantee the safety of the user who > jumps from the source domain to the target domain. Note that protected > cookies (httponly) are one of the safer ways to store information, [js script > can't use > them|[https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage]]. >
[jira] [Updated] (OFBIZ-10413) Remove unused code in `CommonEvents::setFollowerPage`
[ https://issues.apache.org/jira/browse/OFBIZ-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-10413: Fix Version/s: Upcoming Branch > Remove unused code in `CommonEvents::setFollowerPage` > - > > Key: OFBIZ-10413 > URL: https://issues.apache.org/jira/browse/OFBIZ-10413 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > Attachments: OFBIZ-10413-Improve-setFollowerPage.patch > > > `CommonEvents::setFollowerPage` contains two unused variable definition. > After basic search I found that this request handler is used only in > `webapp/partymgr/controller.xml` however I was unable to understand its > purpose, so I have added a comment to add some kind of docstring. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-10413) Remove unused code in `CommonEvents::setFollowerPage`
[ https://issues.apache.org/jira/browse/OFBIZ-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-10413. --- Resolution: Done Hi Mathieu, After investigatin a bit more, I found that it's not related with the data model at all and the attribute "visid" is never used. Also this event method is never used because the pushPage request map is never used. So we can get rid of the whole. Done at revision: 1833505 Thanks for your initial reporting > Remove unused code in `CommonEvents::setFollowerPage` > - > > Key: OFBIZ-10413 > URL: https://issues.apache.org/jira/browse/OFBIZ-10413 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-10413-Improve-setFollowerPage.patch > > > `CommonEvents::setFollowerPage` contains two unused variable definition. > After basic search I found that this request handler is used only in > `webapp/partymgr/controller.xml` however I was unable to understand its > purpose, so I have added a comment to add some kind of docstring. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10413) Remove unused code in `CommonEvents::setFollowerPage`
[ https://issues.apache.org/jira/browse/OFBIZ-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-10413: --- Assignee: Jacques Le Roux > Remove unused code in `CommonEvents::setFollowerPage` > - > > Key: OFBIZ-10413 > URL: https://issues.apache.org/jira/browse/OFBIZ-10413 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Trunk >Reporter: Mathieu Lirzin >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-10413-Improve-setFollowerPage.patch > > > `CommonEvents::setFollowerPage` contains two unused variable definition. > After basic search I found that this request handler is used only in > `webapp/partymgr/controller.xml` however I was unable to understand its > purpose, so I have added a comment to add some kind of docstring. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10433) Fix accounting URL on OFBiz website
[ https://issues.apache.org/jira/browse/OFBIZ-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512179#comment-16512179 ] Swapnil M Mane commented on OFBIZ-10433: Thank you [~sharan]! > Fix accounting URL on OFBiz website > > > Key: OFBIZ-10433 > URL: https://issues.apache.org/jira/browse/OFBIZ-10433 > Project: OFBiz > Issue Type: Bug > Components: site >Reporter: Swapnil M Mane >Assignee: Sharan Foga >Priority: Trivial > Attachments: OFBIZ-10433.patch > > > Change the url '//localhost:8443/accounting' to > [https://localhost:8443/accounting] at > [https://ofbiz.apache.org/developers.html] and > [https://ofbiz.apache.org/business-users.html] > Reference > [link|https://lists.apache.org/thread.html/8f57ee36bfd66b42faf5a3d8e7f562e7e9bb247c32e231d1e34e9529@%3Cdev.ofbiz.apache.org%3E] > to mailing list discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-10433) Fix accounting URL on OFBiz website
[ https://issues.apache.org/jira/browse/OFBIZ-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sharan Foga closed OFBIZ-10433. --- Patch applied > Fix accounting URL on OFBiz website > > > Key: OFBIZ-10433 > URL: https://issues.apache.org/jira/browse/OFBIZ-10433 > Project: OFBiz > Issue Type: Bug > Components: site >Reporter: Swapnil M Mane >Assignee: Sharan Foga >Priority: Trivial > Attachments: OFBIZ-10433.patch > > > Change the url '//localhost:8443/accounting' to > [https://localhost:8443/accounting] at > [https://ofbiz.apache.org/developers.html] and > [https://ofbiz.apache.org/business-users.html] > Reference > [link|https://lists.apache.org/thread.html/8f57ee36bfd66b42faf5a3d8e7f562e7e9bb247c32e231d1e34e9529@%3Cdev.ofbiz.apache.org%3E] > to mailing list discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10433) Fix accounting URL on OFBiz website
[ https://issues.apache.org/jira/browse/OFBIZ-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sharan Foga reassigned OFBIZ-10433: --- Assignee: Sharan Foga > Fix accounting URL on OFBiz website > > > Key: OFBIZ-10433 > URL: https://issues.apache.org/jira/browse/OFBIZ-10433 > Project: OFBiz > Issue Type: Bug > Components: site >Reporter: Swapnil M Mane >Assignee: Sharan Foga >Priority: Trivial > Attachments: OFBIZ-10433.patch > > > Change the url '//localhost:8443/accounting' to > [https://localhost:8443/accounting] at > [https://ofbiz.apache.org/developers.html] and > [https://ofbiz.apache.org/business-users.html] > Reference > [link|https://lists.apache.org/thread.html/8f57ee36bfd66b42faf5a3d8e7f562e7e9bb247c32e231d1e34e9529@%3Cdev.ofbiz.apache.org%3E] > to mailing list discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10428) Don't guess the system file separator
[ https://issues.apache.org/jira/browse/OFBIZ-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-10428: --- Assignee: Jacques Le Roux > Don't guess the system file separator > - > > Key: OFBIZ-10428 > URL: https://issues.apache.org/jira/browse/OFBIZ-10428 > Project: OFBiz > Issue Type: Improvement >Reporter: Mathieu Lirzin >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10428_Don_t-guess-the-system-file-separator.patch > > > The JVM already knows the file separator of the current system when running > gradle so use that value instead of guessing from the operating system > property. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
