Router without usage of #

[tstorch]

OpenUI5 version: all?

Proposal

Supply option to make the router work without the usage of '#' (URL fragment)

Currently, when navigating to a route the URL in the URL bar changes to <base_url>#/<route>. Also by simply entering the URL <base_url>#/<route> and hitting enter the corresponding navigation is internally triggered. It would be nice to have the option to simply use in both cases <base_url>/<route> or any other mechanism, that does not use #, i.e. the URL fragment.

Use case

I want to have an application with OAuth login (implicit grant flow) with a dedicated route/view/controller to handle the callback. The authorization server asks for the callback URL to be configured and forbids the usage of the symbol # in the callback URL, which makes sense as the implicit flow will pass the data back within the fragement of the URL, which would be appended after the # of my URL violating the URL anatomy.

[boghyon]

+1. AFAIK search engines also recommend to avoid relying on #. I guess this is also the reason why Demo Kit has recently moved away from it in order to improve SEO for its content (https://github.com/SAP/openui5/commit/4614eb0caa35fca6258b3bb50b48da5179381679).

[Mabenan]

Problem I see here is with the parameters set in url. Maybe you have noticed that the url is build up like this.

<protocol>://<host>:<port>/<base_url>?<parameters>#/<route>

[tstorch]

@Mabenan I don't exactly get what you want to say here. What exactly ist the problem with the paramaters?

[Mabenan]

<protocol>://<host>:<port>/<base_url>#/<route>?<parameters>

From my experience if you call the app like this the parameters are ignored

If we restructure it to the following

<protocol>://<host>:<port>/<base_url>/<route>?<parameters>

It gets complicated to detect the parameter start

I think this following will still lead to problems with other apis <protocol>://<host>:<port>/<base_url>?<parameters>/<route>

[flovogt]

Hi @Mabenan and @tstorch , thanks a lot for the described scenarios. To offer a router implementation without the hash is definitely a new feature. We will discuss this enhancement in our team.

In other frameworks, e.g. Vue.js its possible to define a mode either hash or history. The history mode enables the router to work without the hash.

[codeworrior]

I agree with @flovogt that this is a (valid) enhancement request.

But I would also like to point out, that using the URL path to represent routes not only requires client side changes. It usually requires a server side counter part that maps all the different URL paths to one (or a few) entry page(s) and injects a corresponding into the returned page. Otherwise, only navigation within a session would work (via the history API), but bookmarks or deep links would result in 404s.

For UI5, this makes it a bit harder to provide this as a general feature, due to the variety of supported server side platforms. But a client side implementation with a limit set of supported backend platforms could at least be a starting point.

[flovogt]

Hi @tstorch , we've discussed this enhancement request and we're looking forward to implement this new feature. The internal BLI is CPOUI5FRAMEWORK-152. Stay tuned for any updates! Thanks for bringing up this topic. Best Regards, Florian

[ritcon]

any updates on this?

I have following use case: add an re-authentication step (addition OAuth login) when user clicks on Approve in a UI5 application.. Unfortunately Auth0 removes everything after the hash in the redirect URI so user is redirected to FLP home after authentication..

Regards,

Robin

[flovogt]

Hi @ritcon , we have it in our backlog. But no planned release date yet. Could you configure the Auth0 to not remove the content after the hash?

[ritcon]

Hi flovogt,

Thanks for prompt response.

I need to check with API team if the option to remove the content after the hash can be disable.. To be honest I don't think it's feasible as OAuth is globally used in our company...Any other work around possible?

My requirement is quite straightforward: perform an extra authentication check when users clicks on an approve button in a Fiori app..

Regards,

Robin

ps. the only work around that I can think of (I cannot image that this is best approach!): pass the redirect URL (with #) via state option and create a launchpad plugin which checks the OAuth response and redirects back to the app based on state value...

[flovogt]

Hi @ritcon, sorry for answering so late. Your scenario is definitely straightforward. However we can not offer any OAuth API support. Were you able to solve your requirement?

[BenjyTec]

I see that this issue was reassigned last week, is there any update or roadmap whether this will be implemented?

[ecker]

Hi @BenjyTec, no, such an enhancement is still open. As mentioned, complementary server-side parts need also to be considered. Sorry, but for the time being, we don't see a realization soon.

[qualiture]

I have the exact same requirement, albeit from a CAP / UI5 application.

While I'm perfectly able to secure the CAP OData endpoints and /app UI5 frontend entirely, ideally I would like to be able to have /app unsecured, and (for instance) /app/secure behind authentication. For the reasons outlined earlier, the hash-based routing does not allow partial securing of the UI5 routes