How to disable spamWaitTime for a single user?

[Daretary]

Tried like this:

Code Select Expand

// Make sure the user isn't spamming the board.
if (!isset($_REQUEST['msg']) || $context['user']['id'] != 444)
spamProtection('spam');So:

Code Select Expand

// Make sure the user isn't spamming the board.
if (!isset($_REQUEST['msg']) || $user_info['username'] != 'userlogin')
spamProtection('spam');
Does not work.

[Arantor]

Why do this, though? There's possibly a better way to do this depending on what exactly you're trying to do (and why).

[Daretary]

Dear Arantor, with the help of a Python script, authorization is followed by sending a message.
That is, two POST requests.
I have to set time.sleep(30) because spamWaitTime = 30 on the forum
I would like to send a message without delay.

[Arantor]

If you're making two POSTs, the first one should be on the flood protection for login, the second for flood protection for posting.

The symptoms you describe are two POSTs for posting a message back to back which doesn't sound like what you want.

What *exactly* are you posting and where? I suspect it's not doing what you think it's doing...

[Daretary]

It's clear. You don't have an answer.

[Arantor]

I only wrote part of the SMF code itself - if you don't trust my ability to answer, don't use SMF.

[Daretary]

if you don't trust my ability to answer, don't use SMF.

Forgive me, but this is an illogical phrase. There is a big difference between using SMF and your ability to answer.

I just wanted to know where to put "if" to give a particular user not to wait 30 seconds. I know the forum root (admin) has this option default. I wanted to get it for a specific regular participant.

[Arantor]

No, I literally wrote part of SMF, but you don't trust my knowledge in SMF to be useful, so why would you trust the software I wrote?

I question your basis; if you were making the correct requests in the first place you wouldn't be getting held up by the flood control system because login (your first request to authenticate) and posting are held in separate queues. Thus I think you're doing something *else* wrong and wanted to know a little more, but hey, you know best.

[Daretary]

This is SMF 1.1.21
Both authorization and sending a message require POST. But the forum says there is an error, as it counted the first POST and started counting 30 seconds from it. It is necessary to do a timeout between two POSTs.

[Diego Andrés]

Did you try with $user_info['id'] ?

[Arantor]

This is SMF 1.1.21

So you're using a platform that's years out of support and long since end of life and hasn't worked on any version of PHP released since 2015 when mysql_* functions were removed in PHP 7. Not that it worked properly in PHP 5.6 either.


$user_info['id'] has the same issue as the OP's use of $user_info['username'] - they're both populated during loadUserSettings, both are in scope in Post2(), but as a result it follows that something else is wrong - spamProtection('login') is called during the auth flow and spamProtection('spam') during the posting flow, which would imply that the auth isn't working as expected, e.g. the cookies returned during the auth flow aren't being attached to the subsequent post.

Which also doesn't make sense because you wouldn't get hit twice against spamProtection('spam') with a full user account if you were properly logged in unless you're hitting the post-message endpoint twice to make two calls to spamProtection('spam').

Which brings me back to 'what exactly are you doing so we can help you debug this?' because you're saying that the auth POST followed by the message POST is getting you hit twice. Alternatively, if you're saying that you want to make two messages back to back (which didn't seem right), there would be a better suggestion by making a suitable endpoint based off SSI.php for that one account that just calls createPost() accordingly.

But again this comes back to you not making it clear what you're trying to do so we can help you...

[Kindred]

If you are using smf 1.1.21, then you have MANY other issues.

That branch is end-of-life. There are known security issues with it that were fixed in 2.0.x and 2.1.x.

That branch does not support current php, and the versions of php it does support are end of life and have known security issues...

So, i suggest fixing your system before worrying about a posting script.

[live627]

I have to set time.sleep(30) because spamWaitTime = 30 on the forum
I would like to send a message without delay.

Hi,

Have you verified that the post is made after the delay?

[Daretary]

I have to set time.sleep(30) because spamWaitTime = 30 on the forum
I would like to send a message without delay.

Hi,

Have you verified that the post is made after the delay?

After the delay everything works fine. I want to be able to send without delay.

Did you try with $user_info['id'] ?

The problem is not WHAT to write, but WHERE. It is quite possible to put global $context; and enter the desired ID.
But I can't find the right places in the code to make it work.

There are known security issues with it that were fixed in 2.0.x and 2.1.x.

Thanks, but 2.x is a buggy thing. Especially Ajax (as it is implemented there - by the example of "quote  selected text"). And especially hooks - it's generally terrible.
The good old SMF 1.1.21, which can be rummaged without mods and hooks with your hands and easily do everything you have planned - this is the standard!
 
 

[Daretary]

Which brings me back to 'what exactly are you doing so we can help you debug this?' because you're saying that the auth POST followed by the message POST is getting you hit twice. Alternatively, if you're saying that you want to make two messages back to back (which didn't seem right), there would be a better suggestion by making a suitable endpoint based off SSI.php for that one account that just calls createPost() accordingly.

There are two POST in my script:

Code Select Expand

p = s.post('https://smf.com/action=login2', payload, allow_redirects=False)

time.sleep(31)

r = s.post('https://smf.com/action=post2;board=111.0', data=form_data, cookies=n_cookies)

That is why you have to put a delay.

[Arantor]

And yet even in 1.1 the login flow takes you through a different part of the spamProtection routine (login vs spam) to prevent hammering on the login route.

I wonder if you not following redirects on the login post is relevant, though... honestly, you could just take the cookie you get and store it - if you login "forever", it'll be good for I think 6 years, as long as you don't replace the password on that user since the cookie contains a secondary hashed version of the password in 1.1.

(Oh, and 1.1 does support hooks, it's one of the big features actually added in 1.1 for integrations, it just doesn't support multiple functions per hook, that was a change added in 2.0 RC4 for mod authors after we had a couple of mod authors demonstrate the value of using the hooks for 1.1 mods.)

Or you could give that user some moderation powers, as users with moderation rights get to bypass the checks. I'd have to look up the exact permissions in 1.1 because I think it's different to that in 2.x but moderate forum members definitely does do the bypass.

[Kindred]

Also, I will note that
1- mods are encouraged to use hooks when possible, because it makes them PORTABLE and not dependent on the order of installation.  *THIS* is the standard of internet scripts these days.

2- Mods in 2.0 and 2.1 do not HAVE to use hooks....   you can still write a mod that uses the package manager routines and edits core files or edit the files yourself directly.

but most importantly -- You are literally running a version with known security reports that will not be patched on a version of php with known security reports that will not be patched...
For someone who seems as technically oriented as you do, that appears to be a strange and poor decision.

[live627]

After the delay everything works fine. I want to be able to send without delay.

The original code you posted might work if you change || (double pipe) to &&

[Daretary]

live627, you are a genius!
Yes, everything is working now.

[live627]

Glad to have helped!

(I may need to lock this thread to end the flame war)