• Resolved akshatjiwan

    (@akshatjiwan)


    Hello,

    I recently upgraded my wordpress to start using ssl certificates. In my database I also rewrote the urls to serve https files instead of http files. For the most mart the site works as expected, however I’m not able to access the admin panel even after I log in correctly using the user that has administrative privileges. It always redirects me to an error page with the following message

    “Sorry you’re not allowed to access this page”

    I tried to create a new admin user and log in with that but the result was the same.

    The wiered thing though is that when I switched back to http(non-ssl server) it started working perfectly again. I was able to login as an admin without any hitch.

    In my wp-config.php I made the following changes:-

    define(‘FORCE_SSL_ADMIN’, true);
    // in some setups HTTP_X_FORWARDED_PROTO might contain
    // a comma-separated list e.g. http,https
    // so check for https existence
    if (strpos($_SERVER[‘HTTP_X_FORWARDED_PROTO’], ‘https’) !== false)
    $_SERVER[‘HTTPS’]=’on’;

    Here is a link to the nginx configuration files that I’m using for my application.

    Can you please help me understand what might be causing this issue?

    Thanks,
    Akshat

Viewing 6 replies - 1 through 6 (of 6 total)
  • Hello Akshat!

    I have not seen this specific behavior before, but I have seen this error message as well as conflicting behavior between HTTP and HTTPS. Here are some notes that I hope will be helpful in your research:

    1. The “Sorry you’re not allowed to access this page” is typically seen when a user doesn’t have any role assigned to it, or is assigned a role that no longer exists for some reason, usually due to corruption in a database table. However, since you are able to login successfully using HTTP…

    2. I have usually seen an issue with a mismatch in HTTP versus HTTPS behavior when the web service settings (i.e. your nginx configs) accidentally point to a different web directory path.

    3. Assuming the above is not the case, perhaps an HTTPS request is not resolving correctly during the login process. Have you tried opening the Developer Tools console in your browser while attempting both the HTTPS as well as the HTTP login to compare and see if any errors are reported?

    4. The wp-config.php code appears to be fine at first glance, but it isn’t strictly necessary to make HTTPS work; it’s only there to force HTTP attempts to be loaded as HTTPS. Have you tried removing this code and testing HTTPS again specifically? (I assume you have to remove the code when you test HTTP and login successfully.)

    This is my first response to a post on these forums, so please forgive any mistakes or confusing text above! If you need me to re-explain anything please let me know. ??

    Hope this helps!
    – Vince

    Thread Starter akshatjiwan

    (@akshatjiwan)

    Thank you Vince for the detailed reply! It was very helpful ??

    I can say with certainty that points #1 and #2 are not causing this issue. Because the user exists in the database and my nginx configuration files are pointing to the same location in both the cases. BTW you can check out the nginx files on github if it helps(https://github.com/ellobd/wp-eb/tree/master/nginx)

    I do have a couple of follow-ups on point #4

    >The wp-config.php code appears to be fine at first glance, but it isn’t strictly necessary to make HTTPS work; it’s only there to force HTTP attempts to be loaded as HTTPS. Have you tried removing this code and testing HTTPS again specifically? (I assume you have to remove the code when you test HTTP and login successfully.)

    Yes I have to change the configuration files during http and https tests. The real problem is that I’m unable to identify the true cause of this issue. These are the steps that I take when moving from one scheme to another

    – I have to change configuration files (wordpress)
    – I have to update the urls in the database

    So these are the questions I have

    1. Is there anything that I might be missing when moving from http to https? Perhaps setting a parameter somewhere that I could have forgotten?
    2. You say that config code is not necessary but that has not been my observation. I can not make https code work at all if the following lines are not present

    if (strpos($_SERVER[‘HTTP_X_FORWARDED_PROTO’], ‘https’) !== false)
    $_SERVER[‘HTTPS’]=’on’;

    Could it mean that there might be something wrong somewhere else?

    Thanks,
    Akshat

    Hello Akshat,

    While you’re correct that the proper way to enable full HTTPS on a site is to make the change to the configuration files and update the URLs in the database, for the purpose of isolating the root cause of this issue, it should not be necessary to change every URL in the database and the configuration files each time you switch from HTTP to HTTPS. HTTPS should be able to work alongside HTTP (though the rewrites may be strong enough to redirect your HTTPS attempts back to HTTP). This is why I said the config code should not be necessary. However! I was incorrect; there are times when HTTP_X_FORWARDED_PROTO code is necessary to prevent a redirect loop.

    So, with all of the above said, the short answer to both your questions is Yes. The long answer involves having you do a bit of troubleshooting yourself. Depending on your web host, your host’s support team may also be able to help.

    1. When you say that you cannot make https code work at all if the “IF” statement is not present, what is the behavior when you try to load HTTPS without those lines present? Does that behavior change when you try to load interior links versus the home page, or when you try to log into wp-admin?

    2. What about point #3 in my earlier reply – have you tried loading the browser’s developer tools and watching the Network tab to view all HTTP/HTTPS requests and see any errors in the console? If so, what have you seen?

    I did look at your Nginx configuration files but nothing immediately struck me as incorrect or strange. However, my experience with Nginx conf files is limited, so take my review with a grain of salt.

    Thanks,
    – Vince

    Thread Starter akshatjiwan

    (@akshatjiwan)

    Thank you once more Vince! You’re right I’ll have to do some experimentation with multiple parameters in order to find out the root cause. But thank you for pointing me in the right direction. I’ve managed to recreate the “bug” on my dev server so making some of these changes has become a lot easier now that I don’t have to worry about permanently breaking anything on production. Its a start I guess ??

    >what is the behavior when you try to load HTTPS without those lines present?

    Well the behavior is exactly like you pointed out. I get infinite redirects when I go to wp_login.php page.

    >Does that behavior change when you try to load interior links versus the home page, or when you try to log into wp-admin?

    The home page and other blog posts work perfectly fine (except in the case when I don’t change all the urls in the database the browser blocks mixed content served over http) The issues that I’m talking about only occur when I try to login to access admin pages. And since I haven’t managed to get past the login screen I can’t really say what happens when the admin pages show up.

    >What about point #3 in my earlier reply – have you tried loading the browser’s developer tools and watching the Network tab to view all HTTP/HTTPS requests and see any errors in the console? If so, what have you seen?

    I tired your suggestion after typing my response previously and although there were no errors on the console I discovered something else that raised more questions. A lot of 302 responses were being returned. In the nginx configuration a proxy cache is being used. I’m not able to actually query the items in the cache but it might very well be possible that when I move from one scheme to the other the cached objects are returned and they somehow cause an error? So that is one more line to investigate.

    Another idea that I have stumbled upon is to use wp rest api. I want to see how things change when I try to login using the api vs the on screen UI. Maybe I’ll uncover something new that will help me solve the main problem.

    Looks like this one is going to take some time ?? But I’ll keep this thread open and update you on any new things I discover.

    As a last resort there is always an option of changing the configuration files themselves. I’ve ashley rich’s nginx configuration files on github (https://github.com/A5hleyRich/wordpress-nginx) and they look quite good. I’ll try to see if the problem resolves itself with that configuration.

    Once more thank you so much for your responses. It gave me ideas on how to attack the problem.

    Thanks,
    Akshat

    Hi Akshat!

    Thanks for the additional information – I now understand the implications of needing the lines because of a reverse proxy so it makes sense that you need them. Thanks for your patience with my learning learning as well! I stumbled upon the following post which may be an easy solution to your issue:
    https://techblog.jeppson.org/2017/08/fix-wordpress-sorry-not-allowed-access-page/

    Are you adding these lines at the top right after the opening <?php line? If not, try moving them up there and see if the “Sorry you’re not allowed to access this page” error goes away.

    Thread Starter akshatjiwan

    (@akshatjiwan)

    Hi Vince

    Apologies for the delayed response. The issue was with nginx configuration. To verify that I simply replaced my nginx configuration with Ashley Rich’s configuration on github and the problems disappeared. Although I didn’t try to debug what was wrong with the original configuration I have a couple of ideas on what might have went wrong. [Please note that they are just theories. I have not been able to test them successfully]

    1. There is no need for proxying wrodpress when you are using nginx as the webserver. It needlessly complicates things. Not only you have to set appropriate headers to the proxy but also in wordpress configuration files. This is simple enough to do in practice but it makes it extremely hard to debug errors. The number of places where things can go wrong increases dramatically. With so many pieces you can’t really say where things are going wrong.

    2. I was not clearing the cache when moving from one scheme to the other. It is quite possible that the session that the cache contained was invalid. Furthermore I had no idea how the proxy cache actually interacts with wordpress. What invalidates the cache? What adds new items to the cache? I could also not find any documentation that explained this well.

    Anyway using a better configuration file has solved my issue. For any one else seeing this thread my recommendation would be to use configuration files that have been tested in a variety of situations rather than writing your own even if it is simple enough to do so.

    Thanks once more for all your help!

    Best,
    Akshat

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘“Sorry you’re not allowed to access this page” after migrating to https’ is closed to new replies.