XF 1.5 Is it possible to identify staff by cookie?

[Alpha1]

We have added a Web Application Firewall (Anti-DDoS) by Stackpath.
These WAF rules can ban / block members. To avoid this happening to staff we would like to whitelist staff members somehow. And then automatically whitelist them.

Is it possible to identify staff by cookie?

 

[Alpha1]

From your answer I gather that this is not stored in a cookie by default.
EDIT: I see that the answer was removed. probably for security reasons.

See:
Step 2: Enable automatic logged-in admin users whitelist rule
https://support.stackpath.com/hc/en...StackPath-WAF-with-your-CMS-Recommended-steps

They created this for Wordpress and are interested in creating somethign similar for XenForo as well. But they need a way to identify staff.

 

[tyteen4a03]

We have added a Web Application Firewall (Anti-DDoS) by Stackpath.
These WAF rules can ban / block members. To avoid this happening to staff we would like to whitelist staff members somehow. And then automatically whitelist them.

Is it possible to identify staff by cookie?

Apologies, I removed my last post because I realised I misunderstood your post.

If your WAF can look up XF's datastore then you should be able to look up user info with the `xf_session` cookie, which contains the session ID. How much of a performance penalty I don't know - depends on where you store your session.

(It's been a long time since I worked with XF1 so my memory's a bit rusty)

 

[nocte]

You could just save an additional cookie with a secret value just for staff with a small addon. If that cookie is present the user should be a staff member. But the secret value should be kept secret. Not absolutely secure solution but for this purpose sufficient I think.

 

[tyteen4a03]

You could just save an additional cookie with a secret value just for staff with a small addon. If that cookie is present the user should be a staff member. But the secret value should be kept secret. Not absolutely secure solution but for this purpose sufficient I think.

Cookies are stored on client machines and should be considered compromised. (this was my original comment by the way, before I realised I misunderstood things)

 

[nocte]

Cookies are stored on client machines and should be considered compromised.

In this case (exclude users from DDOS protection) the additional cookie does not give the user any rights, so I think the cookie solution would be o.k. - if a hacker knows the secret cookie value of a staff member he might also have his session and can log in as a staff member (at least if there's no activated 2FA) and this would be the main problem then, not the DDOS protection. Regarding performance and coding the cookie solution would be the easiest one.

 

[Alpha1]

Is it possible to differentiate between logged in and logged out users from the xf_session cookie?

 

[Jake B.]

Not without checking the database, you can check the xf_user cookie, however. This is stored in the format user_id,token