Hello, I’m trying to create a real-time Jquery call with PHP. The basic behind this logic is to grab another Javascript file every 1 second. The 2nd Javascript file is supposed to grab data from the database. The data will determine either if the user should be logged off or not. This is basically a real-time ban/ auto kick/ auto log off type scenario.
Repeating with scenario:
User A logs in and has always been a good person on the site. User B logs in and talks trash to User A. User A reports User B for inappropriate behavior. A mod goes and bans User B. Now let’s say User B hasn’t refreshed their page and on that page, there is an Ajax form that doesn’t require any refreshing to submit the form. Well, User B can then abuse that and spam the crap out of it until the server goes down because User B has been banned already.
The logic behind this is so that it will automatically kick or refresh the page so that User B gets logged out automatically without them spamming any Ajax form.
Here is my code.
$(document).ready(function() {
window.setInterval(function() {
// Grabbing the javascript file
$.getScript('http://codes.localhost.com/jquery-ban-call.js', function() {
// alert('The javascript file has been called');
});
}, 1000);
});
The problem I am having is that $.getScript only works if the file relates to the current domain. So if I am using http:// localhost.com, it only works if the file is something like http:// localhost.com/jquery-ban-call.js instead of http:// codes.localhost.com/jquery-ban-call.js. Is there another way for Jquery to request for a file every so seconds like how $.getScript does?
Why would you want to redownload a JavaScript file every second? I see absolutely no possible need for this. JavaScript files are not objects to be called, they are static assets like images. They should be cached to increase site performance, which would render any server-side changes to the second js file useless.
If you’re trying to run a function call in the second JS file, loop over that instead of re-downloading the entire file.
Can you put the second JS file on here or http://pastebin.com/ if it’s too large? Maybe we can help clear up the logic.
(It’s also possible I may be just totally off the mark)
When the server checks the ajax attempt to post to see if the user is allowed to post, that problem completely goes away.
With your plan you will end up with thousands of users spamming the server every second checking if they’re still allowed.
With my alternate plan that check occurs only when posting, with a much happier server.
The second Javascript file is all in PHP with the content-type header of text/javascript. I have also modified my .htaccess to replace .js.php and make it .js instead. It works perfectly fine as it would if the file was just a .js file.
The problem at hand is neither the second JS file nor the first JS file. When I change a user’s level to the banned level, there is no redirect. When you refresh the page, the user is logged off like desired.
Then should I be doing this with PHP instead? It sounds like it would be checking to see if the user has a banned level. If they are banned, they get logged off or nothing is done to the form. Is that correct? If it is, that was my first idea, but I thought that if the user isn’t forced out, they will most likely cause more trouble. It’s the same idea like why not just use PHP to check if the user is banned, if they are banned, log them off. Well, thing is, that only works when they refresh the page. My idea is to force them out whether they want to or not if they have violated a term of service. I know it sounds harsh. I just want to make a real-time Jquery call like how sitepoint does with their comments. If you are viewing someone’s topic and a new comment is added in, the new comment automatically shows up on all clients who are viewing the page’s screen. I know this has something to do with long-pulling and what not, but it would be nice to understand which technique works and which doesn’t.
When they are viewing a topic and a new comment is added in, ajax might trigger the request, but it is PHP that retrieves that comment from the database. That is where an extra SQL clause checking where the user is allowed, has great benefit.
I guess I’ll just have to take that approach since I do see that having the server check every few seconds does waste resource. I just find it kind of an easy way out for someone to abuse the system.
Well, there is a school of thought that you don’t want the bad person knowing they’re banned too soon - otherwise they’ll just create a new account and carry on misbehaving. We’ve had that problem quite a few times here.
For example around here, it’s possible for a person to be put on the quiet list, where the posts of a bad person are seen only by that bad person. This gives them the impression that they’re contributing but nobody else responds to them because they can’t see them.
That’s just something that helps to prevent bad people creating mass user accounts. There are other techniques too, but basically you want to focus your efforts on protecting your community - not on helping bad people too much.
Try to rehabilitate them definitely, but try not to encourage bad behaviour.
I see. That actually sounds like a good idea. So basically like a mute system so that when they post something, they think people are seeing it, but just ignoring it? Dang, that never came to mind. Thanks for showing me the light.
Ah, now we have a name for the mute system. Is the correct term for it called “hellbanning”?
So the best way is to not use Javascript for banning, but use different techniques that make people less of a nuisance to the community? So which one of the three from the link is very effective and which ones aren’t much effective?
@Mittineague
Can you move this to “Get started” instead of keeping in the Javascript category? It seems that I am very interested in these techniques and I sort of want to abandon my idea for now.
No, anything you give the client can be manipulated by the client. You shouldn’t trust anything the user gives you or requests, it all needs to be validated by the server.
A nice example of why not to trust, came to me a while ago.
A payment form gave the option of including a gratuity, or a tip, and scripting made sure that it wasn’t a negative figure.
The problem is though, that people can disable scripting. Even worse than that though, they can change the scripting. In this case the negative figure check was removed, and a negative tips were being entered for more than what was paid.
The fundamental lesson here is don’t trust things from the client. Do all of your checks from the server, and only when that layer of security is done, should you consider if for the benefit of the user you should do those same checks from the client-side.
Thank you. Wait, now new questions come to mind. What if you have a public forum. Wouldn’t the guest users be able to see the comments the user makes or not? If not then what if the shunned user gets curious and logs off. Wouldn’t they be able to not see their comments as well? Wouldn’t this make them want to create new accounts and troll more since no one is seeing their comments? I was thinking along the line of shunning both the user and the IP Address, but then again. People have access to VPN and proxy lists. I want to know everything I should before I take a new approach.
Yes, I totally agree with this. I normally don’t do things with client side because anything can be modified with client side. It was just this once that I wanted to do something with the client, but I guess it was the wrong approach.
There will always be a few bad eggs looking to make trouble. Putting someone on a temporary suspension is just one tactic out of a whole range that can be applied.
When someone is causing trouble, you want to bore them to death. They’re only doing it for the excitement, which is why 'Do not feed the trolls!" needs to be more well known.
Having a good community of moderators goes a long way too. They can keep an eye out for multiple registrations from the same IP address, and other signs of trouble.
To get back to the OP’s original question, it sounds like server push is what you’re looking for.
Requests are generally categorized as either push or pull. We typically always deal with pull. That is, the client initiates the request and pulls information from the server. The behavior you want for your ban feature is server push. That is, the server initiates the request and pushes information to the client.
Unfortunately HTTP doesn’t natively support push, so we have to fake it, usually with a trick called long polling. The client iniates a request and the server deliberately takes a long time to send a response. Once something interesting happens on the server (such as a ban) only then does the server generate and send a response.
As others said, you don’t want to implement the security with JS. For example, I can easily mimic this response http://codes.localhost.com/jquery-ban-call.js simply by modifying the dns lookup. I’m not sure what the contents you are generating… if it’s simply a list of good/bad users then i can easily overcome that.
As for spamming the server, you really can’t help that. A user can simply use a ‘proxy’ sites to spam your sites. How does other site deal w/ it? They spend millions on equipments to filter out unwanted traffic. This is all done before HTTP hits the webserver.
Now, what would I do? I would have fun w/ bad user. It depends on how evil you want to be but you can redirect to another URL filled w/ viruses… lol… Of course, I don’t recommend this but there are too many options. As said, you can’t stop him…but you can control what to respond with