Jump to content
OpenLG

Redirect to another URL and browser cache

Recommended Posts

Hi,

I have a couple of restricted templates using the "Redirect to another URL" if the user doesn't have access. I redirect to a custom login page with the {id} tag. On successful login the user then gets redirected to the page he/she was trying to access in the first place (if the user in question has access to the page). You probably get the point.

I now have a user who gets the "too many redirects" browser issue. I haven't been able to reproduce this so it's too early to draw any conclusions.

Anyone else having similar issues?

Also pw seems to always redirect with a HTTP 301 internally, i.e. the "Redirect to another URL" functionality, and these are cacheable in the browser (http://en.wikipedia.org/wiki/HTTP_301). PHP does however by default add headers that should make the browser not use cache: the no-store, no-cache, expires etc. This would effectively make the 301 (permanent redirect) behave like a 302 (temporary redirect), however the browsers have as far as I know have not been particularly good at following the recommendations regarding cache headers.

Is there a reason for always using 301, in the pw core?

Share this post


Link to post
Share on other sites

There's another parameter for PW's redirect function if you're using that in module code or a template to make it redirect with a 302 instead. Is it in a module or template that you're redirecting or are you talking about PW in general?

Share this post


Link to post
Share on other sites

Yes I know of this parameter and my code always use the second parameter for 302s but I'm talking about processwire itself. My code is so far only in templates, no custom built modules.

If you do a

grep -R 'redirect(' ./

in the processwire root dir, you will find a lot of examples. The functionality I'm referring to is under the "ACCESS" tab in "Edit Template" with the label "What to do when user attempts to view a page and has no access?" and in code it's in one of the modules under wire/modules/Process/

Share this post


Link to post
Share on other sites
Is there a reason for always using 301, in the pw core?

We've never seen any negative side effects from using 301s, so that became the default behavior of $session->redirect(). Whereas, there can be negative side effects from using 302s on the front-end of your site (at least with regards to Google). Even if that reason doesn't matter on the admin side, most redirects that PW does internally I would still call fitting the permanent designation, semantically. Though if a browser/software did start applying that literally to just a URL in our context (as opposed to a URL+POST) then we'd be forced to use 302s in some instances.

On successful login the user then gets redirected to the page he/she was trying to access in the first place (if the user in question has access to the page).

This one might make more sense as a 302, I agree.

I now have a user who gets the "too many redirects" browser issue. I haven't been able to reproduce this so it's too early to draw any conclusions.

I've not seen this before, but please let us know what you find.

Share this post


Link to post
Share on other sites

Thanks for your input ryan. Imagine the following scenario:

I have a page with a template that requiers the admin role (with the "Redirect to another URL" set).

  1. The page is visited while not logged in (role = guest?)
  2. User gets redirected with a 301 to a noaccess page
  3. User then logs in with the admin account (or an account that has the admin role)
  4. User visits the page again but since the previous 301 was cached in the browser it instead visits the noaccess page

This was my line of thinking. Sorry for dragging this out but I just want to make sure my point comes across. My point being that if you do a redirect based on some conditional (hasRole('admin') etc.) a 302 might be more suitable since the conditional might return different results from time to time (a user might get stripped of his/her admin role privilege).

As far as SEO goes I do get that 301s are a useful but this isn't about that.

Share this post


Link to post
Share on other sites
User visits the page again but since the previous 301 was cached in the browser it instead visits the noaccess page

Is this what you think happened in the case you mentioned? I can't say as though I've witnessed that behavior, but let me know if you are able to reproduce the redirect loop--it seems plausible in the situation you mentioned.

As far as SEO goes I do get that 301s are a useful but this isn't about that.

301s are useful, but 302s can also be dangerous if used in the wrong place. I was stating this just to clarify why 301 is the default behavior of the $session->redirect function, and why you have to specify a second bool param if you specifically want a 302.

Share this post


Link to post
Share on other sites

I came across this post because I had this redirect problem in a production environment. I could reproduce this in Firefox. The problem also occurs in IE.

I have a template that can only be viewed by users with a specific role.
Based on the template settings, an unregistered user or a user who does not have the required role will be redirected to a different URL (301).
This is done by ProcessPageView::execute().
If the user tried to access the page before logging in and therefore has been redirected once, the redirect will also be performed when the user is logged in later because the browser has cached the redirect.

Possible solutions:

  • Add a unique GET parameter (such as a timestamp) to the URL in the link.
  • Trigger the redirect via API in the template file:
    $session->redirect('/targeturl/', false); // 302

     

  • Paste this hook into your init.php
    wire()->addHookBefore('Session::redirect', function($e) {
    	$url = $e->arguments[0];
    	if ($url == '/login/') $e->arguments(1, false); // change to 302 if target is /login/
    });

 

  • Like 2

Share this post


Link to post
Share on other sites
8 hours ago, kixe said:

Based on the template settings, an unregistered user or a user who does not have the required role will be redirected to a different URL (301).

That sounds like an issue that should perhaps be fixed in the core - when redirecting due to lack of access I don't think this should be permanent redirect because as you say the user may just need to log in and then they should have access. Maybe you can create a GitHub issue for this to get Ryan's take?

  • Like 2

Share this post


Link to post
Share on other sites
9 hours ago, Robin S said:

That sounds like an issue that should perhaps be fixed in the core - when redirecting due to lack of access I don't think this should be permanent redirect because as you say the user may just need to log in and then they should have access. Maybe you can create a GitHub issue for this to get Ryan's take?

I don't think this is a PW issue. I am playing around a bit with this behaviour. The problem is, browsers does not handle this consistent and there does not exist a proper status header. Something like a combination of 401 and 302 (e.g. "Moved Login required") would match this situation. Browsers should never cache those redirects and search engines should handle this also without disadvantages. This does not exist.

Another workaround without redirect should work with the following hook in init.php

// render login for guest users trying to access a disallowed page without redirect
wire()->addHookAfter('ProcessPageView::ready', function($e) {
	if ($this->wire('user')->isSuperuser() || $this->wire('user')->hasRole('client')) return;
	$pid = $this->wire('page')->id;
	$disallowedPageIDs = array(1582, 5584, 5342, 1133, 1607, 5374, 6075, 6605);
	if (in_array($pid, $disallowedPageIDs)) {
		$login = $this->wire('pages')->get('/login/');
		$this->wire('page', $login);
	}
});

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By MoritzLost
      This is a new module that provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions.
      The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu:
      Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides:
      An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README.
      Beta release
      Note that I consider this a Beta release. Since the module is relatively aggressive in deleting some caches, I would advise you to install in on a test environment before using it on a live site.
      Let me know if you're getting any errors, have trouble using the module or if you have suggestions for improvement!
      In particular, can someone let me know if this module causes any problems with the ProCache module? I don't own or use it, so I can't check. As far as I can tell, ProCache uses a folder inside the cache directory to cache static pages, so my module should be able to clear the ProCache site cache as well, I'd appreciate it if someone can test that for me.
      Future plans
      If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind:
      Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions!
      Links
      https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory

    • By verdeandrea
      Hello,
      I am using ProCache v3.1.8 on ProcessWire 3.0.96.
      Everything worked fine in the past, but today I noticed that the css file serverd by procache gives a 410 error. 
      The file is there, I checked.
      I deleted the cached files, I deleted the css file, I looked into the .htaccess file looking for some clues about this problem but nothing worked.
      The only way i can see my website correctly again is disabling ProCache. 
      Has anyone any clue on what could be the cause of the problem or on what should I do to fix it?
      Thanks!
    • By abdulqayyum
      Hy Processwire community,
      There are some problem in fileCompiler cache.
      when i change under the directory \site\templates\ it must change under the directory /site/assets/cache/FileCompiler/site/templates/
      but it does not update and functionality working with /site/assets/cache/FileCompiler/site/templates/ directory.
       
      In this case please suggest me how i clear fileCompiler cache?
      what i have to clear it manually?
      Thanks AbdulQayyum.
    • By stanoliver
      Hi! 
      The following code snippet is part of my markup simple navigation and the url_redirect (url field in the backend) just works fine when I put an special custom url into the url_redirect field.
      <?php $nav = $modules->get("MarkupSimpleNavigation"); // topnav $current = $page->rootParent(); // current root page // subnav echo $nav->render(array( 'max_levels' => 2, 'item_tpl' => '<h4><a class="g8-bar-item g8-hover-black" href="{url_redirect|url}">{title}</a></h4><hr class="sidenav">', 'collapsed' => true, ), $page, $current); ?>  In my seperated breadcrumb navigation I use the following code snippet
      <?php foreach($page->parents()->append($page) as $parent) { echo "<li><a href='{$parent->url_redirect|url}'>{$parent->title}</a></li>"; } ?> Now to the problem: In my first code snippet above the
      url_redirect|url 
      works just fine but when I try something similiar in the second code snippet
      $parent->url_redirect|url
      I produce an server error How do I have to change the second code snippet so that it works in the correct way as the first code snippet does?
    • By modifiedcontent
      I had upgraded my Apache configuration to include PHP7.2 and PHP7.3 for a Laravel-based script on the same server. Somehow it/I messed up a previously fine Processwire site, in a very confusing way.
      The site still looks fine, but editing template files has no effect whatsoever. It is stuck on some kind of cached version. I have already disabled PHP7's OPcache, cleared browser caches, etc, with no effect.
      The pages now apparently come from PW's assets/cache/FileCompiler folder, even though I never enabled template caching for this site.
      I have tried adding "namespace ProcessWire;" to the top of the homepage template file, but then I get this fatal error:
      My functions.php file pulls data in from another Processwire installation on the same VPS with the following line:
      $othersitedata = new ProcessWire('/home/myaccount/public_html/myothersite/site/', 'https://myothersite.com/'); That apparently still works fine; the site still displays data from the other installation, but via the "cached" template that I am now unable to change.
       
      I don't know where to start with this mess. Does any of this sound familiar to anyone? Any pointers in the right direction would be much appreciated. 
       
      Edit:
      Adding "$config->templateCompile = false;" to config.php results in the same fatal error as above. 
×
×
  • Create New...