search

vaadin / flow

Vaadin Flow is a Java framework binding Vaadin web components to Java. This is part of Vaadin 10+.
Apache License 2.0
618 stars 167 forks source link

Whitelist specific redirect URLs as an alternative to Vaadin-Refresh #7679

Open Legioth opened 4 years ago

Legioth commented 4 years ago

Based on a discussion in https://stackoverflow.com/a/60389722/2376954, there may be situations where it's not practical to add the Vaadin-Refresh token to a redirected or otherwise intercepted response.

As an alternative, the client engine could detect whether a redirect has happened (either by migrating to the fetch API or by looking at whether responseURL has changed) and if the new URL matches a rule (e.g. a regular expression) configured for the application, then the new target URL is loaded as a top-level navigation instead of interpreting the response as UIDL.

Legioth commented 4 years ago

It may actually even make sense to look at the content type of the response as well. If it's e.g. text/html instead of the expected application/json, then it may be quite safe to assume that a top-level navigation to the same URL may be appropriate.

knoobie commented 4 years ago

Personally I would prefer your second option with the content type detection.

FYI, we currently rely heavily on the current Vaadin-Refresh mechanism. We use it in our static page redirects after for example Session Timeouts like this:

<meta http-equiv="x-v-ref" content="Vaadin-Refresh: https://domain.com/static-page.html">

HermanBovens commented 4 years ago

@knoobie The Vaadin-Refresh mechanism can stay, this is more about a fallback in case Vaadin-Refresh is not present in the page to which the request was redirected. But if your redirects on Session Timeout are also going to the URL supplied after Vaadin-Refresh then you can remove it since the refresh would happen automatically to this URL when this enhancement is implemented.

mkn1988 commented 3 years ago

Hi, we are having the same problem currently with one of our customers and we can not use the Vaadin-Refresh mechanism, since the ops sadly are not in our hand. What happens at some point is that all traffic at some point is redirected dependending on the tenant to one of the following:

  1. a certain site where they have to press a "I'm still a user and alive" button (not our decision)
  2. an automated service which will after a redirect cascade authorize the user

At the end some session cookie that authorizes against a reverse proxy through which all traffic is routed is exchanged and the original request is performed and returned.

So the second case is really not a problem since it is a transparent call for us, which is either handled by the browser or by the reverse proxy (which I honestly don't know, since we didn't debug that), but the first case makes our application crash.

HermanBovens commented 3 years ago

I've been thinking a bit more about this. I was wondering if it was actually allowed according to the HTTP standard to redirect to an HTML page when the client expect JSON. Some authentication modules might be configured to return status 401 (Unauthorized) instead of redirecting to the login page when JSON is requested. But then I noticed that Vaadin doesn't send Accept: application/json header so this would not be detected. Is there a particular reason that Vaadin doesn't use the Accept header?

Legioth commented 3 years ago

I guess the main reason for not sending an Accept header is that nobody has realized it would make sense to send one. One such reason has now been discovered.