You cannot access this page directly.
-
Hello.
After our website move from shared hosting with Litespeed to dedicated server with nginx, we experience this error.
You cannot access this page directly.
When trying to log in.
We have set the correct permissions to the folder/files.As i see, you do not suggest altering the code, but this would kill us, since we love the way WordPress Social Login works.
Can we have a bit help in here?
What is the cause of this error? Can we modify something on the server side and get it working without altering the code? The same files/db are still working and not producing the error on the shared hosting, while they give error “You cannot access this page directly.” on our dedicated server.
Thanks in advance.
https://www.ads-software.com/extend/plugins/wordpress-social-login/
-
that error usually mean an issue with php sessions..
beside, I have tried to run WP/WSL on a couple of different nginx setup and It seems to be working fine for me..
could you either:
– reinstall wsl, goto WP Social Login > Help & Support > WSL Diagnostics to check if its a php session issue an nothing else,
– reinstall wsl, goto WP Social Login > Help & Support > Website Information and send me the generated report
– send me your nginx config/setup (only the relevant part of it)that will help me immensely debugging the issue.
There is no Website Information in Help & Support Tab.
In diagnostics, i recieve fail in:
PHP Sessions are not working correctly or this page has been accessed directly.
If you see an error “Warning: session_start…”, then there is a problem with your PHP server that will prevent this plugin from working with PHP sessions. Sometimes PHP session do not work because of a file permissions problem. The solution is to make a trouble ticket with your web host.
I have tried altering the path by defining it in wp config and all other files. I tested it by doing a php echo, and it works. All files and folders of plugin and sessionpath are set to 755.
Our nginx configuration is:
server {
# Configure the domain that will run WordPress
listen 8080;
server_name domain.gr https://www.domain.gr;
port_in_redirect off;
server_tokens off;
autoindex off;client_max_body_size 15m;
client_body_buffer_size 128k;# WordPress needs to be in the webroot of /var/www/ in this case
root /var/www/vhosts/domain.gr/httpdocs/;
index index.html index.htm index.php;
try_files $uri $uri/ /index.php?q=$uri&$args;
error_log /var/log/php-fpm/www-error.log;# Define default caching of 24h
expires 86400s;
add_header Pragma public;
add_header Cache-Control “max-age=86400, public, must-revalidate, proxy-revalidate”;# Do not allow access to files giving away your WordPress version
location ~ /(\.|wp-config.php|readme.html|licence.txt) {
return 404;
}# enforce www (exclude certain subdomains)
if ($host !~* ^(www|subdomain))
{
rewrite ^/(.*)$ $scheme://www.$host/$1 permanent;
}# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
# Don’t log robots.txt requests
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}# Rewrite for versioned CSS+JS via filemtime
location ~* ^.+\.(css|js)$ {
rewrite ^(.+)\.(\d+)\.(css|js)$ $1.$3 last;
expires 31536000s;
access_log off;
log_not_found off;
add_header Pragma public;
add_header Cache-Control “max-age=31536000, public”;
}# Aggressive caching for static files
# If you alter static files often, please use
# add_header Cache-Control “max-age=31536000, public, must-revalidate, proxy-revalidate”;
location ~* \.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|od$
expires 31536000s;
access_log off;
log_not_found off;
add_header Pragma public;
add_header Cache-Control “max-age=31536000, public”;
}# pass PHP scripts to Fastcgi listening on Unix socket
# Do not process them if inside WP uploads directory
# If using Multisite or a custom uploads directory,
# please set the */uploads/* directory in the regex belowa
location ~* (^(?!(?:(?!(php|inc)).)*/uploads/).*?(php)) {
try_files $uri = 404;
fastcgi_split_path_info ^(.+.php)(.*)$;
fastcgi_pass unix:/var/run/domain.socket;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_intercept_errors on;
fastcgi_ignore_client_abort off;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
}# Deny access to hidden files
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}}
# Redirect all www. queries to non-www
# Change in case your site is to be available at “www.yourdomain.tld”
#server {
# listen [::]:8080;
# server_name https://www.yourdomain.tld;
# rewrite ^ $scheme://yourdomain.tld$request_uri? permanent;
#}Please advise, thanks in advance!
To sum it up :
php session works with your php test but not for WSL
nginx have nothing to do with thiswell then maybe its your reverse proxy, in case you are using one
We are using Varnish.
Is there any exception that we can add for your plugin in order to be working with Varnish?
Thanks for your help, i really appreciate this, as i am in despare and i really like your plugin.
well Im not familiar with varnish nor server conf on general, but Ill try to help you as much as I can..
could you check if hes dropping cookies when caching unauthenticated users requests. if this the case, then let it send all cookies and give wsl another try just to make sure
I am pasting you the config of my Varnish default configuration file for my domain. There is a section about cookies, i hope this helps you understand the problem as you already know how the plugin cookies work exactly.
# This is a basic VCL configuration file for varnish. See the vcl(7)
# man page for details on VCL syntax and semantics.
#
# Default backend definition. Set this to point to your content
# server.
#
backend default {
.host = “127.0.0.1”;
.port = “81”;
}# Drop any cookies sent to WordPress.
sub vcl_recv {
if (!(req.url ~ “wp-(login|admin)”)) {
unset req.http.cookie;
}if (req.url ~ “^/registration/.*$” || req.url ~ “^/wp-admin/.*$” || req.url ~ “^/my-details/.*$” || req.url ~ “^/profile/.*$” || req.url ~ “^/profile” || req.request == “POST”) {
return (pass);
}# Always cache the following file types for all users.
if (req.url ~ “\.(aif|aiff|au|avi|bin|bmp|cab|carb|cct|cdf|class|css|dcr|doc|dtd|exe|flv|gcf|gff|gif|grv|hdml|hqx|ico|ini|jpeg|jpg|mov|mp3|nc|pct|pdf|png|ppc|pws|swa|swf|txt|vbs|w32|wav|wbmp|wml|wmlc|wmls|wmlsc|xml|xsd|xsl)$”) {
unset req.http.Cookie;
}
}sub vcl_fetch {
set beresp.ttl = 20m;
return(deliver);# Don’t allow static files to set cookies.
if (req.url ~ “(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?[a-z0-9]+)?$”) {
# beresp == Back-end response from the web server.
unset beresp.http.set-cookie;}
# Allow items to be stale if needed.
set beresp.grace = 24h;
}sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = “HIT”;
} else {
set resp.http.X-Cache = “MISS”;
}
}try to temporary disable theses 3 lines but like i said, I’m really not familiar with Varnish so I don’t know for sure
if (!(req.url ~ “wp-(login|admin)”)) {
unset req.http.cookie;
}also, could you send me you site url by email: hybridauth at gmail
This error is showing “error_log” server.
Maybe can help?
Nothing works after upgrading wordpress to 3.5.1. worked fine with 3.5PHP Fatal error: Class ‘Hybrid_Providers_Facebook’ not found in /home/XXXXXXX/public_html/wp-content/plugins/wordpress-social-login/hybridauth/Hybrid/Provider_Adapter.php on line 85
[28-Feb-2013 17:08:39 UTC] PHP Warning: session_start() [function.session-start]: open(/public_html/sessions/sess_880799efbac7a3dbb47275c4d3f54c2d, O_RDWR) failed: No such file or directory (2) in /home/XXXXXX/public_html/wp-content/plugins/iphorm-form-builder/includes/common.php on line 31This is what you see in the debugger. –>
3. PHP Sessions
FAIL!
PHP Sessions are not working correctly or this page has been accessed directly.Most likely an issue with PHP SESSION. The plugin has been made to work with PHP’s default SESSION handling (sometimes this occur when the php session is disabled, renamed or when having permissions issues).
If you are using a reverse proxy like Varnish it is possible that WordPress’s default user cookies are being stripped. If this is the case, please review your VCL file. You may need to configure this file to allow the needed cookies.
This problem has also been encountered with WP Engine.
If you see an error “Warning: session_start…” on the top of this page or in the Error log file, then there is a problem with your PHP server that will prevent this plugin from working with PHP sessions. Sometimes PHP session do not work because of a file permissions problem. The solution is to make a trouble ticket with your web host.Alternatively, you can create the sessions folder in your root directory, then add session_save_path(‘/path/to/writable/folder’) at the top of the following files:
– wp-config.php
– wp-content/plugins/wordpress-social-login/wp-social-login.php
– wp-content/plugins/wordpress-social-login/authenticate.php
– wp-content/plugins/wordpress-social-login/hybridauth/index.phpAs of now I am getting this error “You cannot access this page directly.”
I don’t know what happen .Please help as I need to sort it out ASAP.The same plugin working with other sites brilliantly.Any help from your side would really appreciated.
Thanksgetting the same error upon install…
had the same problem. this is how we solved it:
goto WP Social Login > Help & Support > WSL Diagnostics to check if its a php session issue an nothing else.
Follow these instructions (https://hybridauth.sourceforge.net/wsl/faq.html):
"You cannot access this page directly." Error Most likely an issue with PHP SESSION. WSL requires a PHP's default SESSION setup in order to works; and this issue could occur due to the following: Your webhost have purposely disabled PHP's SESSION. Eg: WP Engine. PHP's SESSION have been renamed php.net/manual/en/function.session-name.php. File permissions stackoverflow.com/questions/ask. If you are using a reverse proxy like Varnish it is possible that WordPress's default user cookies are being stripped
OR these
3. PHP Sessions
FAIL!
PHP Sessions are not working correctly or this page has been accessed directly.
Most likely an issue with PHP SESSION. The plugin has been made to work with PHP’s default SESSION handling (sometimes this occur when the php session is disabled, renamed or when having permissions issues).If you are using a reverse proxy like Varnish it is possible that WordPress’s default user cookies are being stripped. If this is the case, please review your VCL file. You may need to configure this file to allow the needed cookies.
This problem has also been encountered with WP Engine. If you see an error “Warning: session_start…” on the top of this page or in the Error log file, then there is a problem with your PHP server that will prevent this plugin from working with PHP sessions. Sometimes PHP session do not work because of a file permissions problem. The solution is to make a trouble ticket with your web host.
Alternatively, you can create the sessions folder in your root directory, then add session_save_path(‘/path/to/writable/folder’) at the top of the following files:
– wp-config.php
– wp-content/plugins/wordpress-social-login/wp-social-login.php
– wp-content/plugins/wordpress-social-login/authenticate.php
– wp-content/plugins/wordpress-social-login/hybridauth/index.phpi created the sessions folder and added the session_save_path(‘/path/to/writable/folder’ to the files above. works fine now!!
- The topic ‘You cannot access this page directly.’ is closed to new replies.