Og:url causing issues with Facebook sharing for Private Group

#21

Hi all :slightly_smiling:

By default, s2Member will redirect a user who doesn’t have access to protected content. The redirection points to your Membership Options Page where you can display anything you’d like. Whenever s2Member performs this redirection it calls upon wp_redirect_w_mop_vars(), which also contains a hook, so that developers can customize this further if they’d like to.

The hook can be seen here and this is the name of that hook:

ws_plugin__s2member_after_wp_redirect_w_mop_vars

So if you would like the redirection to point to the login page and include an additional redirection back to the original content once they log in, you can use an s2Member plugin file like this.

Create: wp-content/mu-plugins/s2-redirect-wp-login.php

<?php
// Requires PHP v5.4 (or higher).
add_action('ws_plugin__s2member_after_wp_redirect_w_mop_vars', function(array $vars) {
   wp_redirect(add_query_arg('redirect_to', urlencode($vars['seeking_uri']), wp_login_url()), $vars['status']);
});

This redirects a visitor without access, to: /wp-login.php?redirect_to=[original URL]. Once they login they will be returned to the page they were trying to access. Assuming they have an account they can log in with, and that their account is associated with a Membership Level that allows them to access the page they were trying see prior to logging in.

You could take this a step further and only redirect to the login page if other conditions apply; e.g., only if you know for sure that they are not logged in yet.

<?php
// Requires PHP v5.4 (or higher).
add_action('ws_plugin__s2member_after_wp_redirect_w_mop_vars', function(array $vars) {
   if (!is_user_logged_in()) {
       wp_redirect(add_query_arg('redirect_to', urlencode($vars['seeking_uri']), wp_login_url()), $vars['status']);
   }
});

Taking it another step further I can limit this behavior to a specific page ID as well.

<?php
// Requires PHP v5.4 (or higher).
add_action('ws_plugin__s2member_after_wp_redirect_w_mop_vars', function(array $vars) {
   if (!is_user_logged_in() && is_page(123)) {
       wp_redirect(add_query_arg('redirect_to', urlencode($vars['seeking_uri']), wp_login_url()), $vars['status']);
   }
});
#22

Another option could be [s2MOP /] as seen here.

#23

@jaswsinc thanks for trying to help, I’ve removed the original hack on both my main development site and the clean test install and replaced with s2-redirect-wp-login.php as recommended. It still does not work on either, in fact it’s slightly worse as I am just getting a 404 error with this, rather than the default welcome page with the hack @KTS915 suggested. I’ve raised it with my host to see if they have any ideas. I know you’ve both said these work elsewhere but I was also thinking of trying a different host, because if I can prove to myself that it works somewhere else that gives me peace of mind and definitely points to something with the Krystal set-up.

#24

Hi @jaswsinc, I’ve received the following response from my hosting company, they made a small change and this is now working but they are not sure if it is secure and suggested checking. It just seems to include base64_decode, which is what @KTS915 had in the code he originally recommended.

Dear Nigel,

Thank you. I had to reset the IP restriction log in order to continue our tests.

Upon requesting http://newsite.axescouts.org.uk/2016/06/05/cubjam-100/ from a fresh session, the browser is redirected to

http://newsite.axescouts.org.uk/wp-login.php?redirect_to=LzIwMTYvMDYvMDUvY3ViamFtLTEwMC8%3D

This page also loads a couple of resources:

/wp-admin/load-scripts.php?c=0&load%5B%5D=jquery-core
/wp-content/plugins/s2member/s2member-o.php?wsplugin_s2member_js_w_globals=1&qcABC=1&ver=160503-2684530571

After entering credentials, the following data is submitted with the login form

POST /wp-login.php HTTP/1.1
Host: newsite.axescouts.org.uk
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://newsite.axescouts.org.uk/wp-login.php?redirect_to=LzIwMTYvMDYvMDUvY3ViamFtLTEwMC8%3D
Cookie: wordpress_test_cookie=WP+Cookie+check
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 158
log=test-volunteer&pwd=[redacted]&wp-submit=Log+In&redirect_to=http%3A%2F%2Fnewsite.axescouts.org.uk%2FLzIwMTYvMDYvMDUvY3ViamFtLTEwMC8%3D&testcookie=1

The redirection token is clearly present as 2FLzIwMTYvMDYvMDUvY3ViamFtLTEwMC8%3D

The server’s response is determined by the web application:

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Tue, 21 Jun 2016 07:22:40 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: close
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/
Set-Cookie: wordpress_7f2525d41996e9f2b82adb8c43c67322=test-volunteer%7C1466666560%7C9zs7r3d4ke0Rew1NCHchDDkuWXKIcpxJwCsIWthxsja%7C38496c30509db024eda1640fc519726d261fc2f365e26cfef45753fcdf369ac8; path=/wp-content/plugins; httponly
Set-Cookie: wordpress_7f2525d41996e9f2b82adb8c43c67322=test-volunteer%7C1466666560%7C9zs7r3d4ke0Rew1NCHchDDkuWXKIcpxJwCsIWthxsja%7C38496c30509db024eda1640fc519726d261fc2f365e26cfef45753fcdf369ac8; path=/wp-admin; httponly
Set-Cookie: wordpress_logged_in_7f2525d41996e9f2b82adb8c43c67322=test-volunteer%7C1466666560%7C9zs7r3d4ke0Rew1NCHchDDkuWXKIcpxJwCsIWthxsja%7Ce6ad8aa8e9844c6035c508dc28090de8749de7ad53d2c597c98bf748ffc10bc4; path=/; httponly
Location: http://newsite.axescouts.org.uk/LzIwMTYvMDYvMDUvY3ViamFtLTEwMC8=

LzIwMTYvMDYvMDUvY3ViamFtLTEwMC8= is just base64 encoded /2016/06/05/cubjam-100/

I think this is the problem - the above response, the Location header is still giving the encoded URL…

I tried altering your code in /home/axescout/public_html/NewSite/wp-content/mu-plugins/s2-redirect-wp-login.php

from

wp_redirect(add_query_arg('redirect_to', urlencode($vars['seeking_uri']), wp_login_url()), $vars['status']);

to

wp_redirect(add_query_arg('redirect_to', urlencode(base64_decode($vars['seeking_uri'])), wp_login_url()), $vars['status']);

and this appears to have fixed the issue - but I’m unsure if this is secure, or how it might interact with the rest of your application. I highly recommend you show this information to the plugin author for comment.

Kind regards

Steve Sant
Krystal Hosting Ltd

#25

Looks like a bug fix to me. Cool. Yup, that’s secure. It’s only the URI for redirection. Base 64 encoding is not encryption anyway, so you’re not exposing anything there that wasn’t already exposed. You’re just translating it to a format that WordPress redirect_to can understand. All good there.

#26

Awesome, thanks everyone for your help. I can now buy the pro version and get the rest of it all set up :smiley: