Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 293910

External application is redirected to frontpage in maintenance mode

$
0
0

Problem/Motivation

When authorized headless consumer requests the site in maintenance mode, he gets 302 code instead of 503. Generally if it follows redirect it gets 503, but if homepage is forbidden for consumers with HTTP server/balancer configs (or just Shield module used) consumer gets 401 response code, and tries to login again, and only than gets 503 code.

Except of long chain instead of simple response, there are 2 things:
- Not all external consumers follow redirects. The redirect is logged, and then ticket is created to Drupal team, which could be really hard to understand what happened. 503 response makes it clear. Also if JSON format is requested in "_format" query param, it is lost, and consumer gets unexpected HTML answer. (text/plain is unexpected too, but it is much more readable and understandable for API consumer)
- If the consumer is frontend application and Drupal homepage is protected - it looks that user uses it, and some time he see 403 page or login form. He tries to login again just to see "server offline" screen. It really puts out some users.

Steps to reproduce

- Forbid public access to homepage with .htaccess or Shield.
- Log in to the site.
- Put site into the maintenance mode.
- Try to request any endpoint or page.

Expected:
- Consumer is notified with 503 code about site maintainance.

Actual:
- 302 and then 401/403 code is returned.

Proposed resolution

a) If the redirect is important I propose to wrap it with response format check, like HTML subscriber does to display 403/404 custom page.

b) I don't understand what benefits the redirect does (why is below). It was introduced in #1998228. Remove it, patch is below.

As far as I understand the redirect after user logout leads him to homepage to avoid 403 error if current page isn't public. But as a rule site configured to provide login block on custom 403 page or in our case (backend isn't public) shows /user/login page as 403 one. So I don't see any need to redirect the user - he can see designed 403 behavior after maintained end, but not occasionally will be moved to frontpage.


Viewing all articles
Browse latest Browse all 293910

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>