Name&Password - Chrome deprecate the actual system

[SimoneMilesi]

From today annoucement Google Chrome, starting from June, will block all the requests with user and password in the URL.

From official Developers' site another article

And UI5? Yes, exactly, uses this way to communicate with the Backend.

There is any idea on how to deal this deprecation?

[AndreasKunz · Accepted solution]

Hi Simone,

we are looking at this.

UI5 does certainly not build such URLs, just like that.

I assume you use an ODataModel with user and password parameters? In this case we feed user and password as separate parameters into the datajs third-party library. This library in turn passes them on as distinct parameters to the browser's XMLHTTPRequest.open(...) method. The URL still contains no user/password. But it's not fully clear what happens then. Tests with today's nightly build of Google Canary indicate that its own XMLHTTPRequest constructs this URL, which leads to the announced failure. So this behavior is not specific to UI5, but applies for any usage of the XHR object (which is more or less the base of the modern web) with its official user/password parameters, which have NOT been deprecated. In this light, the Chrome change looks like a strange/overambitious move that will break many things in the web.

However, for productive scenarios handling plaintext user/password within apps is anyway questionable. I'm not an expert, but that SAML/OAuth authentication where an access token is retrieved from a distinct login page might be better. Nevertheless, we keep an eye on this and might contact Google.

Regards

Andreas

[SimoneMilesi · Accepted solution]

Hi Andreas,

Thanks for your kind and clear answer.

Yes, we pass user and password as parameters in the OData Model (we are using V2) constructor.

i don't understand your last sentence

However, for productive scenarios handling plaintext user/password within apps is anyway questionable. I'm not an expert, but that SAML/OAuth authentication where an access token is retrieved from a distinct login page might be better. Nevertheless, we keep an eye on this and might contact Google.

Take in mind we are using UI5 integrated into a Angular2 application and we are pretty new into the whole authentication procedure.

Are you suggesting a different approach? We weren't able to find any other option than passing user and password in our constructor (it's more than possible we missed it!).

Thanks again!

I keep open the question to check any other possible update!

Simone

[junwu · Accepted solution]

what's your runtime? sap server?

[SimoneMilesi · Accepted solution]

Hi Jun Wu,

No, we have an Angular application on Apache server (Debian Jessy).

[junwu · Accepted solution]

it is not ui5 issue. you have to find a way to secure your app and sso(or whatever) to sap if you want to call odata

[SimoneMilesi · Accepted solution]

Sorry, but i just partially agree, Jun Wu.

Yes, having user and password in the url call isn't the best thing.

Still, the call works only if the user is under VPN otherwise he cannot access the resource.

Plus we have a reverse proxy to avoid Cross Site problem, so our backend system it's masked and secure (for what security could mean in SoftDev) and work on HTTPS (trusted and secure certificate)

And this is an UI5 problem, since UI5 library allows to connect passing user and password on the constructor method of OData Model.

If the library allows that, how couldn't it be an UI5 problem? 🙂

i checked the library to see if there is a way to login (some method) to a SAP system and... well, the only moment i found it's the OData Model creation.

Now i'm trying to investigate this approach, but i don't know if and how i could match with UI5.

[AndreasKunz · Accepted solution]

Hi, just a quick reply to this one.... regarding alternative authentication I'll try to answer to your top-level comment.

> If the library allows that, how couldn't it be an UI5 problem? 🙂

The library is not a fail-safe sandboxed playground that prevents any possible error. But I get your point: it is an official API offered by UI5 where you can give user and password, so you can reasonably expect it to work. But we are in exactly the same position: we just pass these parameters to the official API of the XMLHttpRequest.open() method offered by the browser, so WE also expect this official API to work (remember: the now-deprecated URL is in this case built by the browser itself behind the scenes!).

So we expect Google to recognize that while overall their change makes total sense, the XMLHttpRequest API should not be broken in this way. As I wrote, we are investigating and getting in contact. Either they will keep it working, or we might create a workaround (if not, there would need to be very intense communication about this issue - you are not the only one using it).

Regards

Andreas

[AndreasKunz · Accepted solution]

Somehow I replied to myself... the above was meant to reply to your last reply to Jun Wu.

[SimoneMilesi · Accepted solution]

Thanks for the update Andreas and i know you and your team (i guess you are involved into UI5 project!) are in the same situation.

And, as i said to Jun Wu, i can agree it's not a pure UI5 problem/issue (even more if we have some workaround to apply, like SSO/SAML which i've still to investigate) but the feeling UI5 should be somehow involved is there 🙂

It's like i buy a boat and the engine made by a third party has some issues: i go to the shop where i bought the boat to complain.
(Again, this isn't a complain on UI5, just i'm a biiiiit worried for next June!)

Thanks so much for your interest in the issue!

[AndreasKunz · Accepted solution]

Hi Simone, yes, I am involved with UI5 and I understand that as a user you correctly expect it to just work. Your boat example is good. 🙂 Luckily, we are not sending you to the engine manufacturer, but we try to clarify the issue with the engine manufacturer on our own. Thanks for pointing us to this engine malfunction, by the way. 😉

I'm may not promise anything, but I can tell you that it's very much in our interest that everything continues to work well after June. One way or another.

Regarding alternatives, I have to say that I cant really give you a lot of advice. It's not my area of expertise and it also depends a lot on the services you are working with (which login mechanisms are supported). The best thing would be to investigate the respective service technology documentation.

Regards

Andreas

[AndreasKunz · Accepted solution]

Hi Simone, you can also follow the discussion progress with Google here: https://bugs.chromium.org/p/chromium/issues/detail?id=707761

Regards

Andreas

[SimoneMilesi · Accepted solution]

i'm not a big expert on how things work under the hood but i can see that this change will cause a lot of problems to the addons and the extensions too.

Plus the user:password@site is a W3C standard, right?

Thanks for the update!

[AndreasKunz · Accepted solution]

Hi Simone, as you can read here, Google has changed their implementation (usage of user+password in XMLHttpRequests will remain working). As far as I see, this means that usage of the ODataModel with user and password will continue to just work fine. At least my test which failed in the Chrome nightlies recently works well again now. 🙂

Thanks again for pointing us to this topic! This not only helps the ODataModel to continue working, but maybe also saved Google from breaking many other sites in Chrome. 😉

[SimoneMilesi · Accepted solution]

i followed the bug/discussion and it's me thanking you and your colleguee from UI5 for taking my little note (indeed, it's all my colleguee's fault who saw that while developing, i just started the thread! ) and saved our work!

Thanks again!