Ajax request fails with modal dialog for 401

[takesson]

When using OpenIDC a refresh is required after some time. Ajax requests typically fails with 401.

Should it:

• Refresh transparently?
• Display dialog with refresh button?

Seen with the embedded details dialog. Any other ajax that might trigger separate from a page load?

[solsson]

Refresh transparently?

Would this be OIDC-vendor specific? For example keycloak-js uses a hidden iframe that somehow tracks expiry and triggers a refresh before it happens.

Display dialog with refresh button?

A modal would be quite intrusive because the user might want to navigate somewhere else, which would also revalidate the session. Displaying an error message in-place on 401, where the refreshed content would appear, is probably feasible. I haven't checked yet if there's more XHR based content, in addition to embedded details.

How would a server opt-in such interpretation of 401? Or would it be fine to always display a reload link regardless of auth setup?

[solsson]

More AJAX

• repos.txt contents at the top of dir listing

[takesson]

The current 401 error has appeared now and then with Basic Auth as well, when the Browser just "feels like" not sending the auth header due to the user not yet having visited the server root (e.g. arrived via an emailed link or a bookmark). A reload would not help though... only a visit to server root with a redirect back mechanism. I don't care about that any more, aiming for OpenIDC.

Refresh transparently?

Would this be OIDC-vendor specific? For example keycloak-js uses a hidden iframe that somehow tracks expiry and triggers a refresh before it happens.

Maybe, but we are vendor neutral by using mod_openidc which in turn can be configured against any OpenIDC provider transparent to rweb.

I think a transparent refresh is a reasonable approach, at least initially.

• Very minimal effort to implement.
• Much less intrusive than the current browser-modal.

Display dialog with refresh button?

A modal would be quite intrusive because the user might want to navigate somewhere else, which would also revalidate the session. Displaying an error message in-place on 401, where the refreshed content would appear, is probably feasible. I haven't checked yet if there's more XHR based content, in addition to embedded details.

That could be a nice solution. Too much work?

How would a server opt-in such interpretation of 401? Or would it be fine to always display a reload link regardless of auth setup?

It would be fine always. Some hook to override the URL could be useful if we want to address the Basic Auth issues (but it might not be important any more).

[takesson]

More AJAX

• repos.txt contents at the top of dir listing

There are a few AJAX calls on the details page as well.

But, most of these happen just after the page load. This issue probably only applies to stuff that can be triggered long after the page load (manually or periodic refresh).

[solsson]

Maybe, but we are vendor neutral by using mod_openidc which in turn can be configured against any OpenIDC provider transparent to rweb.

I think a transparent refresh is a reasonable approach, at least initially.

I interpreted "transparent refresh" as retrieving the refresh token and revalidation timestamp and use a REST call to a refresh endpoint. That would be specific to mod_openidc + endpoint config. But a better term for that is Revalidate.

With transparent refresh you mean that any 401 from an AJAX call is allowed to trigger a page reload?

Given the stale scope of rweb we could possibly conclude together that such a solution is fine. It would be incompatible with features like backend based autocomplete in form fields.

[takesson]

I interpreted "transparent refresh" as retrieving the refresh token and revalidation timestamp and use a REST call to a refresh endpoint. That would be specific to mod_openidc + endpoint config. But a better term for that is Revalidate.

With transparent refresh you mean that any 401 from an AJAX call is allowed to trigger a page reload?

Yes, "page reload" is a better term. And by transparent I mean without displaying any dialog (modal or not). Maybe the term should be "immediate page reload".

Given the stale scope of rweb we could possibly conclude together that such a solution is fine. It would be incompatible with features like backend based autocomplete in form fields.

Right, I would be an issue with large forms that user starts filling in long after the page load. Possibly the copy dialog in rweb (browse target folder) but the form has so few fields so it is not worth worrying about the lost data.

We are actually improving our (limited) react UIs by ensuring that state is maintained on the url. These UIs are very likely to remain open in a tab because they await background activity.

[solsson]

https://github.com/Reposoft/rweb/releases/tag/v1.8.4

[takesson]

Works as expected, the refresh happens.

Unfortunately, the embedded details page that triggers the refresh is not displayed until the user moves the cursor again and waits.

It's good enough. No more error dialogs that make the site seem broken.