Catch ajax errors globally when server goes away or other errors occur

[PVince81]

Whenever the following happens:

• maintenance mode is enabled (HTTP 503)
• server becomes unavailable (HTTP 503)
• user is logged out (session expired)
• server has intermittent connection issues (HTTP 400 or others)

if it happens during an ajax call, the error isn't always caught and processed properly, so the user might see strange behavior.

One idea would be to implement global ajax handlers using https://api.jquery.com/category/ajax/global-ajax-event-handlers/ and provide a default mechanism for when 503 is returned or whenever the user gets logged out.

It might not work for all apps, so apps might still need to do special handling in other cases.

@nickvergessen you had a ticket about the files app looping if I remember well ? Please link it here.

@butonic @blizzz did some preliminary work on catching errors

CC @LukasReschke FYI

[nickvergessen]

Can not find the issue anymore, so maybe we just discussed it and never created it.

[oparoz]

I agree. When uploading a new version of an app, I always have to check the network tab to see if I'm getting 503 errors because the app doesn't stop working when it gets them.

[DeepDiver1975]

@PVince81 is there a solution at hand? Something we can fix for 8.2? or 9.0?

[PVince81]

@DeepDiver1975 the only solution I know of is what you implemented yourself: #16783

[ghost]

This issue will fall off 8.2 if not resolved by 6 Oct

[butonic]

since #16783 is closed I am adding this to oc9 to test if shibboleth session timeouts are handled gracefully with tha webdav based approach. However, since ANY ajax call will be redirected I don't think it matters an we will need to reopen #16783 anyway ...

[PVince81]

@butonic the current webdav approach will redirect if a 401 error is returned by the server.

[butonic]

Which does not help wit 30x redirects that are created by apache redirecting Ajax calls to the i do when the shibboleth session lifetime has ended. Furthermore, it seems jQuery sees Ajax redirects as having status 0 for whatever reason. Webdav is only half the solution.

Imo all oc Ajax calls need to handle redirects, because we cannot anticipate what apache or nginx or proxy or firewall or file firewall rule sits between the browser and the server and might redirect us...

[PVince81]

Then we might need to global solution proposed by @DeepDiver1975 too.
I'd also need to check to make davclient.js use jquery's ajax too to have it covered by the global stuff. (currently it uses plain XmlHttpRequest)

[PVince81]

@butonic is there a way to simulate this on a regular Apache server ? Setup a misconfigured apache module ?

[butonic]

hm, adding a conditional Redirect rule for an Ajax route to .htaccess should do it.

[PVince81]

Any docs I could look at ? (I have no clue how to do this, sorry 😄)

[butonic]

in the .htaccess mod_rewrite section add a

  RewriteRule ^index.php/core/ajax/share.php.*  "https://heise.de"  [R,L]

to the end. That will redirect the ajax call when fetching the shares after clicking on the share Icon in the filelist. Probably a better idea to Redirect to a local page.

You will get followup errors in the console and the spinner will never finish spinning.

[PVince81]

Cool, thanks.

[PVince81]

So far it seems that ajax calls automatically follows redirects.

Doing some research, maybe there are workarounds: http://stackoverflow.com/questions/9177252/detecting-a-redirect-in-jquery-ajax

[PVince81]

This says it is impossible: http://stackoverflow.com/a/2573589

But one trick proposed here http://stackoverflow.com/a/24715958 is that we set a specific custom header in ALL our ajax responses. Then if the jQuery ajax response doesn't contain it, then it means it was a redirect or not an ajax answer (but a plain page instead).

This reminds me of the old topic about detecting whether we're getting a full page as a response by checking if Content-Type was JSON or XML: #15357 (or not 100% that)

[PVince81]

@butonic what page does a SSO fail redirects to ? ownCloud's login page ?
There is also a suggest to add a special header on the login page's response. Then check for that response in the ajax response to find out if we just got the login page, and react accordingly (redirect to the real login page)

[DeepDiver1975]

@butonic what page does a SSO fail redirects to ? ownCloud's login page ?

the redirect goes to the web page of the idp - a redirect to some url out there in the wild

[PVince81]

Hmmmm... and if that URL isn't in the same domain we might even get a cross-domain fail

[butonic]

@PVince81 yes, cors needs to be set in the config to allow ajax to the idp to make this detectable without Errors.

[PVince81]

Ok, so this means we need to not only detect 503, 401 but also detect:

• ajax errors in case the IDP is not set for CORS, looks like this would be possible http://stackoverflow.com/a/30004160
• ajax redirects in case the IDP is in the same domain, (still needs a good solution to detect redirects)

[PVince81]

I'm first going to revive #16783.
But also I'll check whether it is still possible for apps to override this and have their own handlers, just in case.

[MorrisJobke]

Fixed by #16783

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.