Registration Link Expiring

Hello. I am having a problem with customers who do not click the registration link right away getting the error message that their link has expired. In another closed topic about this same issue Eduan said:

“If the link didn’t really expire, because the time limit you gave the link hasn’t passed, and yet it gives this error.”

This implies that I have given the link a time limit. I had no idea this was an option. Thus, it must be set to a default. How do I adjust this?

Thanks so much!

Hello Erin,

Does the problem happen right away? In other words, do they get a “link expired” message as soon as they check their email? Or does it work as expected and only works a certain amount of time (of which I’m not sure how much it is)?

– Eduan

The link works initially, but then expires very quickly. It might be valid for 24 hours, but not sure. I need to extend that to at lest 48 hours or longer.

Erin, can you try another URL shortening service? [hilite path]Dashboard -› s2Member® -› General Options -› URL Shortening Service[/hilite]

Hello Cristian and everybody with expiring links,

since there is no option to buy a real gift membership for the site (but I read many threads on this forum, that it’s coming in next major release – however these are all closed), we told our customers to just buy the membership and then send the welcome email to whoever needs to get the gift.

However these links expire quite often. And it’s actually not tinyurl failing, the error message appears on the site when they click the link in email:

“Your Link Expired:
Please contact Support if you need assistance.”

If you could make sure these Gift certificates get implemented on time, it would solve two issues at once.

So – I tried to look into wp-content/plugins/s2member/includes/classes/register-in.inc.php as that’s there the message appears. And there it is – 2 day limit on the registration URL:

apply_filters ("ws_plugin__s2member_register_link_exp_time", "2 days", get_defined_vars ())

So this is designed that way. It would be good if this would be documented in the s2Member PayPal options and button screens. There is only a mention that the “Specific Post/Page Access” links become invalid in 72 hours, but not that each registration expires like that.

It’s not true that the links don’t expire in s2Member. Or is there some strange coincidence? Here’s the gift button code if it helps – perhaps this is the only kind which expires in 72 hours?:

[s2Member-PayPal-Button level="1" ccaps="" desc="Gift membership - forward the email with registration link once you pay to your friend" ps="paypal" lc="" cc="USD" dg="0" ns="1" custom="www.site.com" ta="0" tp="0" tt="D" ra="30" rp="1" rt="Y" rr="BN" rrt="" rra="1" image="default" output="button" /]

Fix – I added this into mu-plugins/s2hacks.php, there should be less complains now.

add_filter( 'ws_plugin__s2member_register_link_exp_time', 'fv_mcs_ws_plugin__s2member_register_link_exp_time' );

function fv_mcs_ws_plugin__s2member_register_link_exp_time( $time ) {
  if( $time == '2 days' ) {
    $time = '14 days';
  }
  return $time;
}

I’m not sure if anybody figured this out in the past – could you please make sure that findings like this go into the s2Member plugin settings screens, so that people don’t wonder why the registration links expire.

Thanks,
Martin

• This reply was modified 3 years, 12 months ago by  Foliovision. Reason: added button code

Hello Cristián and everybody at s2,

also one simple additional question – why do these links have to expire at all? I assume the same link can’t be used for registration twice. Or is that just a precaution?

Thanks,
Martin

Thanks for the tip(s) Martin.

I believe they expire only for precaution, security in other words. :)

– Eduan

Thanks for the heads up on this thread :-)

Yes, that is correct. It’s simply an additional line of defense. A registration link contains a Paid Subscr. ID (encrypted in the link itself), which s2Member will ONLY allow ONE paid registration with. If the link is used by a customer, it cannot be used again to perform another paid registration where someone obtains paid access.

Hello Jason,

thanks for stopping by. We are still getting these warnings.

I added some notification code into the includes/classes/register-in.inc.php files, so I know which conditional statement fails. So next time a client complains about not being able to use the registration link, we know what happened:

1. This one fails most often:

if (($reg_cookies = c_ws_plugin__s2member_register_access::reg_cookies_ok ()) && extract ($reg_cookies) /* Needed? */)

It’s not clear what the functions in the condition do. Could you please let us know if that’s a proper check if somebody is trying to register twice, or what could it be? I can see around 5 different PayPal I-S6… keys in 20 of my notifications. So it appears the same person tries multiple times before giving up.

Is that come issue with cookies?

2. This one also failed a few times:

if (count ($register) === 6 && $register[0] === "subscr_gateway_subscr_id_custom_item_number_time" /* Does the checksum value match up here? */)

I have a var_dump kind of statement in my email notification and it reports that $register is NULL. Seems like the GET parameter in the registration link was not decoded properly. Perhaps it was messed up by tinyurl?

The ultimate goal here would be to provide better messages to clients I think. Like “Please check if you have Cookies enabled”, or “Please check if the link opened in its full length from email” – although if should, since you use tinyurl for that.

Thanks,
Martin

Hello Jason,

1. I checked all the 10 people which had these issues – all of them appear to be registered properly. I will double check if we registered any of them by hand.

So perhaps we can disregard these warnings, but it would be nice to know what’s going on and what that check is doing.

Thanks,
Martin

Thanks for the follow-up :-)

Just to clarify in this thread. Registration Access Links self-expire as an additional line of defense (i.e. this tightens security, it’s NOT the only line of defense). Typically, a customer completes checkout and is sent a Registration Access Link via email. That link is good for 2 days (48 hours) by default. This is a scenario that is repeated many times in the free version of s2Member®, where PayPal Buttons have been integrated as opposed to s2Member® Pro Forms, which do NOT use Registration Access Links at all (the process is smoother for a customer).

Having two full days to click a link granting you access to something that you just paid money for, and have not received yet, is usually enough for a customer. In situations where it’s not enough, for any reason, a customer may contact you about this, and it would be a good idea to generate a new Registration Access Link for them from the Dashboard. See: Dashboard -› s2Member® -› PayPal® Buttons -› Registration Access Links

Or, if you would like to increase this time frame, please use the Filter that s2Member exposes.
ws_plugin__s2member_register_link_exp_time

How To Increase This Time Frame

Please create this directory and file:
/wp-content/mu-plugins/s2-hacks.php
(NOTE: these are MUST USE plugins, see: http://codex.wordpress.org/Must_Use_Plugins)
(See also: http://www.s2member.com/kb/hacking-s2member/)

<?php
add_filter('ws_plugin__s2member_register_link_exp_time', 's2_register_link_exp_time');
function s2_register_link_exp_time($what_s2_says)
	{
		if($what_s2_says === '2 days')
			return '10 days';
		// Anything compatible with PHP's strtotime() function will work here.
		
		return $what_s2_says; // Default value.
	}
&#91;/hilite&#93;

<h4>How To Customize The 503 Error Message, Should A Link Expire</h4>

Please create this directory and file:
/wp-content/mu-plugins/s2-hacks.php

(NOTE: these are MUST USE plugins, see: http://codex.wordpress.org/Must_Use_Plugins)
(See also: http://www.s2member.com/kb/hacking-s2member/)

<?php
add_filter('gettext_with_context', 's2_translator', 10, 4);

function s2_translator($translated, $original, $context, $domain)
	{
		if($context === 's2member-front' && $domain === 's2member')
			if($original === '<strong>Your Link Expired:</strong><br />Please contact Support if you need assistance.')
				return 'My custom message with HTML markup.';
		
		return $translated; // Default translation value.
	}

• This reply was modified 3 years, 11 months ago by  Jason (Lead Developer). Reason: Adding 503 sample code

@Foliovision

I added some notification code into the includes/classes/register-in.inc.php files, so I know which conditional statement fails. So next time a client complains about not being able to use the registration link, we know what happened.

1. This one fails most often:

if (($reg_cookies = c_ws_plugin__s2member_register_access::reg_cookies_ok ()) && extract ($reg_cookies) /* Needed? */)

It’s not clear what the functions in the condition do. Could you please let us know if that’s a proper check if somebody is trying to register twice, or what could it be? I can see around 5 different PayPal I-S6… keys in 20 of my notifications. So it appears the same person tries multiple times before giving up.

That’s interesting. This has never been brought up before that I remember. I’m not aware of any issues with s2Member’s handling of this scenario. However, s2Member’s cookies are encrypted using your s2Member Security Encryption Key. So changing your Key could result in lots of issues like you’re describing.

See: Dashboard -› s2Member® -› General Options -› Security Encryption Key

On the other hand, seeing errors here would not be that uncommon (if there is a logging routine attached to it). Some users will have expired Registration Access Links, and so s2Member is just doing it’s job.

2. This one also failed a few times:

if (count ($register) === 6 && $register[0] === "subscr_gateway_subscr_id_custom_item_number_time" /* Does the checksum value match up here? */)

I have a var_dump kind of statement in my email notification and it reports that $register is NULL. Seems like the GET parameter in the registration link was not decoded properly. Perhaps it was messed up by tinyurl?

Well if you’re suspicious there is a problem with the embedded tinyURL, try generating a Registration Access Link for yourself from the Dashboard. Click it, and watch where you land (in the address bar of your browser). Look at the query string in the final URL. Is everything there? I don’t see why it wouldn’t be :-)

It actually sounds to me like your server is excluding certain values from the query string. I’ve seen this occur on servers that use Mod Security. You might want to have a look at this article. See: Knowledge Base » Mod Security, Random 503/403 Errors. Mod Security (or another security app on your server perhaps), might be stripping query string values from the HTTP request because it thinks they look suspicious. Testing a Registration Access Link for yourself and doing some debugging with this should tell you. Please let us know if you stumble onto a bug. I’ve been unable to reproduce this in our lab though.

Please let us know if problems persist :-)

How To Customize The 503 Error Message, Should A Link Expire

Please see this post: http://www.s2member.com/forums/topic/registration-link-expiring/#post-37928

Hello Jason,

That’s interesting. This has never been brought up before that I remember. I’m not aware of any issues with s2Member’s handling of this scenario. However, s2Member’s cookies are encrypted using your s2Member Security Encryption Key. So changing your Key could result in lots of issues like you’re describing.

There is actually no key in our settings. It says: “Security Encryption Key ( optional, for tighter security )”

Well if you’re suspicious there is a problem with the embedded tinyURL, try generating a Registration Access Link for yourself from the Dashboard.

I tested some of these tinyURL links already and they worked.

We actually received no complains about these two scenarios. I’m wondering if some users might run some antivirus software in their mailboxes and this software could be clicking these links and perhaps messing them up a bit. But I’m not an expert in antiviruses, so it’s just an idea.

Thanks,
Martin

Thanks for the follow-up :-)

I tested some of these tinyURL links already and they worked.

We actually received no complains about these two scenarios. I’m wondering if some users might run some antivirus software in their mailboxes and this software could be clicking these links and perhaps messing them up a bit. But I’m not an expert in antiviruses, so it’s just an idea.

I would log the $_SERVER['HTTP_REFERER'] value, along with the IP address and $_REQUEST variables so you can see a little bit more about who these odd links are coming from. You might find they’re coming from search engines hitting your site, after picking these links up somewhere across the Internet. Often times, people will attempt to share their registration links in blogs posts or in chat rooms, but they get things wrong, or they miss details, etc. Logging should reveal things like this.

Hello Jason,

good idea! I added it, I will stop by if I notice anything weird.

Thanks,
Martin

Hello Jason and everybody,

I checked my logs after a couple of days.

1. Regarding the first check which fails often and seems to be related to Security Encryption Key or cookies:

if (($reg_cookies = c_ws_plugin__s2member_register_access::reg_cookies_ok ()) && extract ($reg_cookies) /* Needed? */)

Most of the time, it happens for user agents like Apache-HttpClient/4.0.1 (java 1.5) or similar. Or this one contains McAfee in it: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; AskTbAD4/5.12.2.16749; McAfee)

We also got no client complains, so it really looks like just scripts.

2. Regarding the other one which looks like a problem with tiny URL:

if (count ($register) === 6 && $register[0] === "subscr_gateway_subscr_id_custom_item_number_time" /* Does the checksum value match up here? */)

We got 4 of these errors since I added the extra log. Unfortunately, there is no HTTP_REFERER in $_SERVER. However we can see the cookies and the one for Google Analytics (if I’m not mistaken) often contains strings like utmcsr=facebook.com. This applies to 2 errors, then there is one more with McAfee again and one more with 'HTTP_VIA' => '1.1 ng........tmof.in.telstra.com.au:3128' which looks like some kind of weird proxy.

So it looks like some people share the link on Facebook and some of them user some antivirus which triggers the links. It should be fine.

Thanks,
Martin