SMF 1.1.19 The registration issue after 1.000.000 Member ID

[mktek]

Hello,

I use SMF 1.1.19

Before the site hasn't got 1.000.000 members ID, when a new member wants to register with my site, it was logged in my site automatically not to meet any problem.

But, after the my site has got 1.000.000 members ID, when a new member wants to register with the site, gets this error:  "You were unable to login.  Please check your cookie settings.".  While new member is thinking not able to register with the site, in fact that, the registration is completed. But, new member doesn't realize that.

How can I solve this problem?

Sorry for my bad English.

[Arantor]

The limit even in SMF 1.1.19 on member ids is over 8,000,000 not 1,000,000. There should be absolutely no problems unless you have mods that do bad things.

[mktek]

Thanks for your answer, Mr. Arantor,

But, there is a problem!

I've just installed a new SMF 1.1.19 which hasn't got any mods. When I register that testing site, I didn't meet any problem. But, when I change the smf_members/AUTO_INCREMENT >1.000.000, I came across the same cookie error which I tell you my first message.

Please, can you register my testing site to see the problem by yourself?

................

[Arantor]

It's strange because it only kicks in on registration; the account is perfectly fine once logged in as evidenced on your test site.

It's more weird because the cookie looks right too. However I don't honestly expect us to spend a lot of time chasing down bugs in a 7 year old system that we're going to be marking End-of-Life soon.

[mktek]

I have no choice, I must continue to use 1.1.X. My site is a very very big site and has extreme content. I've modified the lots of attribute.

No one can help us unless you. If you can help me, I would be grateful to you.

[Arantor]

Well, there's going to come a time when we stop doing security fixes for SMF 1.1.x - likely next spring or so, so if a vulnerability emerges, you could well get hacked. I would seriously consider planning for an upgrade.

[emanuele]

Problem is that the same issue affects 2.0 as well, and I suppose 2.1 too...

[Arantor]

I didn't bother to test 2.0, but I don't see *why* that should be. Nothing in the code suggests any kind of limit on that specific thing.

That said, logins aren't broken so the normal session test isn't failing but let's go nuts and try something anything.

Load.php, find this code:

Code Select Expand

if (preg_match('~^a:[34]:\{i:0;(i:\d{1,6}|s:[1-8]:"\d{1,8}");i:1;s:(0|40):"([a-fA-F0-9]{40})?";i:2;[id]:\d{1,14};(i:3;i:\d;)?\}$~', $_COOKIE[$cookiename]) == 1)

Replace with

Code Select Expand

if (preg_match('~^a:[34]:\{i:0;(i:\d{1,7}|s:[1-8]:"\d{1,8}");i:1;s:(0|40):"([a-fA-F0-9]{40})?";i:2;[id]:\d{1,14};(i:3;i:\d;)?\}$~', $_COOKIE[$cookiename]) == 1)

LogInOut.php, find:

Code Select Expand

if (isset($_COOKIE[$cookiename]) && preg_match('~^a:[34]:\{i:0;(i:\d{1,6}|s:[1-8]:"\d{1,8}");i:1;s:(0|40):"([a-fA-F0-9]{40})?";i:2;[id]:\d{1,14};(i:3;i:\d;)?\}$~', $_COOKIE[$cookiename]) === 1)

Replace with:

Code Select Expand

if (isset($_COOKIE[$cookiename]) && preg_match('~^a:[34]:\{i:0;(i:\d{1,7}|s:[1-8]:"\d{1,8}");i:1;s:(0|40):"([a-fA-F0-9]{40})?";i:2;[id]:\d{1,14};(i:3;i:\d;)?\}$~', $_COOKIE[$cookiename]) === 1)

Subs-Auth.php:

Code Select Expand

if (isset($_COOKIE[$cookiename]) && preg_match('~^a:[34]:\{i:0;(i:\d{1,6}|s:[1-8]:"\d{1,8}");i:1;s:(0|40):"([a-fA-F0-9]{40})?";i:2;[id]:\d{1,14};(i:3;i:\d;)?\}$~', $_COOKIE[$cookiename]) === 1)

Replace with:

Code Select Expand

if (isset($_COOKIE[$cookiename]) && preg_match('~^a:[34]:\{i:0;(i:\d{1,7}|s:[1-8]:"\d{1,8}");i:1;s:(0|40):"([a-fA-F0-9]{40})?";i:2;[id]:\d{1,14};(i:3;i:\d;)?\}$~', $_COOKIE[$cookiename]) === 1)

[margarett]

Just tested, it happens with both 2.0 and 2.1

And I cannot find that code in Load.php :-/

[Arantor]

Did you look in a 2.0 or 1.1 installation? That came from my 1.1.19 test site.

[margarett]

2.0 and 2.1.

Will go try in 1.1.19, then (although I didn't provoke the problem in that version )

[Arantor]

Well this *is* in the 1.1.x support board

[emanuele]

I didn't bother to test 2.0, but I don't see *why* that should be. Nothing in the code suggests any kind of limit on that specific thing.

Because while registering the member id comes from registerMember that comes from mysql_insert_id (i.e. an int), instead when logging in, the member is comes from the database and is a string:

Code (login) Select Expand

a:4:{i:0;s:7:"1000011";i:1;s:40:"ee8e1ca189071887c8832566052bde33732325e4";i:2;i:1572910516;i:3;i:2;}

Code (registration) Select Expand

a:4:{i:0;i:1000012;i:1;s:40:"ae522329a363a18eb0a000c7503e0336c889d5fc";i:2;i:1383698456;i:3;i:2;}

[Arantor]

If that's true, why isn't it always broken? Why it is only broken for numbers > 1000000?

On the other hand, the code I indicated does explicitly look for a serialised int with 1 to 6 digits... which would break with 1000000+.

[emanuele]

Because of the regexp you corrected:

Code Select Expand

(i:\d{1,6}|s:[1-8]:"\d{1,8}")
when registering the part regarding the integer is taken in consideration (i.e. \d{1,6}), instead when logging in, the second part is taken in consideration (i.e. s:[1-8]:"\d{1,8}").
Does it sound right?

[Arantor]

Except the string part looks fine; it's accepting a serialised string of 1-8 digits, matching \d 1 to 8 times, as it should. Except the other part WILL fail because it's expecting something 6 digits long...

[emanuele]

Exactly:
login = string => success
registration = int => fail

[Arantor]

So the regexp I suggested would actually fix it - I wrote the paragraph and while I was writing it I had a sudden thought and did a search on {1,6} on the source and forgot to update my paragraph fully

[margarett]

Well, that seems to fix the issue

[Arantor]

This has been fixed in 2.1, so I'm going to treat this one as solved more permanently.