[
https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645558#comment-16645558
]
Jacques Le Roux commented on OFBIZ-10307:
-----------------------------------------
{quote}First, the patch is faulty
{quote}
Actually no, as your copy shows the patch is applied. It's just that it has
been created under Windows (with TortoiseSvn to be more precise). So it has the
CR+LF EOLs. But patch is smart enough to apply it. It just suggests that it
could be
{quote}Next, the code does not compile on my computer
{quote}
You missed to apply the OFBIZ-9833 patch. I mentionned it in this Jira while
answering to you the " 20/Jul/18 19:48" (point 3).
{quote}Why don't you combine conditions and get something cleaner out?
{quote}
Why do you want that?
The idea is to have the code easy to read.
For instance I need a non null authorizationHeader, to check it with
jwtValidation(). If it's null, no need to process further. Hence the 1st block
which returns "success". That should be the case most of the time, when no
authorizationHeader has been passed. The sooner the better, preprocessors like
checkJWTLogin are called at each request. That's the main reason for this 1st
block.
To "combine conditions " I'd have to pass a null authorizationHeader to
jwtValidation() and return a null value. But then I'd need to differentiate the
2 cases (null or ERROR_MESSAGE). Using a switch Statement (or worse a cascade
of if/else) after jwtValidation() would not make the code clearer, quite the
contrary, and, as mentionned earlier, less performant.
Now, jwtValidation() calls JWTManager.validateToken (from Deepak's work at
OFBIZ-9833) which returns an ERROR_MESSAGE in case of issue. A simple test on
ERROR_MESSAGE with a clear log error message and we are done there.
Then I need to extract and check the userLogin from the result of
jwtValidation(). That's what do getUserlogin() which intrinsically takes care
of log messages. In case of error we can get out.
Same for storeUserloginFailed().
{quote}Also the name checkTenant is confusing
{quote}
Which name would you use?
{quote}Overall, I don't feel great about having a critical piece of
authentication done hastily like this.
{quote}
You must be kidding. I'm working on this feature for months, and took into
account all the remarks, notably yours. It can hardly be said that it's "done
hastily". Maybe you can write your own version of checkJWTLogin() and the
community can discuss about the benefits of our both versions. That would be a
positive way to get out of this blocking situation.
{quote}Perhaps more eyes need to be on it.
{quote}
Sure, Nicolas was already positive and I followed his suggestion on names:
[https://markmail.org/message/yxr5ye4j7sqedsmf]
So I'll be happy to have other feedbacks, but please not in months, not even
weeks! Overall, the code is short and simple. The only part which is not
visible in the patch are the CORS expressions. They are in the description
here, and I can rehearse them again:
{code:java}
Header set Access-Control-Allow-Origin "https://localhost:8443";
Header set Access-Control-Allow-Headers "Authorization"
Header set Access-Control-Allow-Credentials "true"
{code}
> 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 <webapp> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
