WordPress.org

Ready to get started?Download WordPress

Forums

Theme My Login
URI breaks on some redirects (5 posts)

  1. kisshomaru
    Member
    Posted 1 year ago #

    Any chance you could encode the redirect link with base64.
    There is this problem with some Apache server configs when some codes in the URI are refused, for example: %2F or %252F.
    For example if the sessions expires, I am sent to frontend to login with TML and then back on redirect, something like this:
    https://example.com/login/?redirect_to=https%253A%252F%252Fexample.com%252Fgoo%252Fwp-admin%252Fedit.php%253Fpost_type%253Dpage&reauth=1
    Which eventually results to a big 404 that even the server can't handle (it bypasses all other custom error control):
    https://example.com/log-in/https%3A%2F%2Fexample.com2Fwp%2Fwp-admin%2Fedit.php%3Fpost_type%3Dpage
    This will bring a server 404.
    So basically I'm looking for encoding redirects. Is this possible?

    http://wordpress.org/extend/plugins/theme-my-login/

  2. Jeff Farthing
    Member
    Plugin Author

    Posted 1 year ago #

    This probably has to do with the "http://" within the query argument. Is TML causing that to happen?

  3. kisshomaru
    Member
    Posted 1 year ago #

    I think it is a wp feature but I believe TML can't handle it. More details:
    When trying to access a backend page when the session is expired (after a day or so - maybe less), I am redirected to the front-end TML login page. The URL that I'm redirect to is this (log-in being the TML page):
    https://example.com/log-in/?redirect_to=https%253A%252F%252Fexample.com%252Fwp-admin%252Fnetwork%252F&reauth=1
    This is handled properly and I get to enter user/pass creds on this page.
    The message embedded on the TML page (coming from WP I beleive, is: Please log in to continue. )
    Now, upon entering the credentials, I am properly authenticated, but the redirect does not work resulting in 404. This is the URI:
    https://example.com/log-in/https%3A%2F%2Fexample.com%2Fwp-admin%2Fnetwork%2F
    See how it was given directly after the log-in. Now I believe there are two solutions:
    1. TML encrypts the further link in base 64 and leaves me to handle my 404.
    2. TML actually tries to redirect to the link (does it have code for redirects on re-authentication?), however the link after the /log-in/ still needs to be encrypted.
    This is an apache well known issues on most servers that the %2F is not handled in URIs because of security threats, which means that this type of URL needs to be encrypted in order to work. Here is a good article about the problem (many more if searching for it):
    http://www.jampmark.com/web-scripting/5-solutions-to-url-encoded-slashes-problem-in-apache.html
    You guessed right that I can't make apache AllowEncodedSlashes=on.
    I know this is a corner case, but it would be greatly appreciated if it is fixed.

  4. kisshomaru
    Member
    Posted 1 year ago #

    To answer your original concern, it is not the "http://" inside the uri, but the way it is coded.
    %252 for slash works (initial), versus %2F that does not. The best solution is to encrypt it all with base 64 (and try to solve the redirect :)). See, if I change by hand the unhandled 404 into this (%252 instead of %2F):
    https://example.com/log-in/https%3A%252%252example.com%252wp-admin%252network%252
    Then it will handle the error (no more apache issue) - gives me a 404 that I can handle. TML still does not redirect (which is the second issue), resulting in a handled 404, but at least works.

  5. kisshomaru
    Member
    Posted 1 year ago #

    You might ask as well, how is it possible that a 404 is different than another 404. In this case it is... don't ask me why, but this cannot be intercepted even by .htaccess. It comes directly from apache and it cannot be handled by me in any way. Ugly as ...

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic