[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 > 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, 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 > navigating from a domain to
[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:
Description:
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]].
*Note: finally I add to use a more secure way and introduced
{{webappName.securedLoginId cookies}} to replace autoLogin cookies. They work
they same way but prevent a possible vulnerability. This is explained at the
bottom of this Jira.*
# To jump from a domain to another I use Ajax to send a JWT token in a HTTP
header (as recommended by CORS standard). The JWT token contains only the
userLoginId information.
# For authentication, I use the checkExternalServerLogin pre-processor in the
same vein than checkExternalLoginKey. It checks a JWT token is present in the
HTTP header of the request and if present uses the userLoginId to sign in the
user on the target domain. I must say that the devil is in the technical
details (of CORS) and I'll not explain that here.
was:
This will use a JWT Token authentication to get from one domain, where
[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:
Description:
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]].
*Note: finally I add to use a more secure way and introduced
{{webappName.securedLoginId cookies}} to replace autoLogin cookies. This is
explained at the bottom of this Jira.*
# To jump from a domain to another I use Ajax to send a JWT token in a HTTP
header (as recommended by CORS standard). The JWT token contains only the
userLoginId information.
# For authentication, I use the checkExternalServerLogin pre-processor in the
same vein than checkExternalLoginKey. It checks a JWT token is present in the
HTTP header of the request and if present uses the userLoginId to sign in the
user on the target domain. I must say that the devil is in the technical
details (of CORS) and I'll not explain that here.
was:
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
[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: Description: 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]]. Note: finally I add to use a more secure way and introduced # To jump from a domain to another I use Ajax to send a JWT token in a HTTP header (as recommended by CORS standard). The JWT token contains only the userLoginId information. # For authentication, I use the checkExternalServerLogin pre-processor in the same vein than checkExternalLoginKey. It checks a JWT token is present in the HTTP header of the request and if present uses the userLoginId to sign in the user on the target domain. I must say that the devil is in the technical details (of CORS) and I'll not explain that here. was: 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
[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 > 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, 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 > navigating from a domain to another to
[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 > 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, 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
[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 > 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, 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
[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 > 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 > navigating from a domain to another to guarantee the safety of the user who > jumps from the source domain
[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 > 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 > > > 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] [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.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 > 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 > > > 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
[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 > 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.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 > > > 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
[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-test from example.patch OFBIZ-10307.patch OFBIZ-10307-test.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 > from example.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 > > > 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 >
[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 > 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, 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] [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 > 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, 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]]. > # To jump
[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] [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-test.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.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]]. > # To jump from a domain to another I use Ajax to send a JWT token in a HTTP > header
[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: Description: 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]]. # To jump from a domain to another I use Ajax to send a JWT token in a HTTP header (as recommended by CORS standard). The JWT token contains only the userLoginId information. # For authentication, I use the checkExternalServerLogin pre-processor in the same vein than checkExternalLoginKey. It checks a JWT token is present in the HTTP header of the request and if present uses the userLoginId to sign in the user on the target domain. I must say that the devil is in the technical details (of CORS) and I'll not explain that here. was: 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
[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: Description: 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[1] 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[2]. # To jump from a domain to another I use Ajax to send a JWT token in a HTTP header (as recommended by CORS standard). The JWT token contains only the userLoginId information. # For authentication, I use the checkExternalServerLogin pre-processor in the same vein than checkExternalLoginKey. It checks a JWT token is present in the HTTP header of the request and use the userLoginId to sign in the user on the target domain. I must say that the devil is in the technical details (of CORS) and I'll not explain that here. [1] [https://s.apache.org/qLGC] [2] [https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage] was: 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
[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: (was: OFBIZ-10307.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.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 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 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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 > 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 >Priority: Major > Fix For: Upcoming Branch > > Attachments: 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 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 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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-test.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 >Priority: Major > Fix For: Upcoming Branch > > Attachments: 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 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 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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: Description: 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 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 was: 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 > 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 >Priority: Major > Fix For: Upcoming Branch > > Attachments: 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
[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: Description: 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 was: 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. > 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 >Priority: Major > Fix For: Upcoming Branch > > Attachments: 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 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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 > 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 >Priority: Major > Fix For: Upcoming Branch > > Attachments: 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. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
