There’s tons of issues with glitch, it takes multiple tries to use, people can easily give themself a role if you just name the glitch creation, it’s not worth it. 000webhost is always running unless it’s inactive for over a month I believe.
Sure, the limits are a bit low, but it’s a trade-off.
The only real issue with Glitch lately has been custom domains, as @chessebuilderman stated.
The reason people are able to rank themselves in your groups is because you haven’t protected your endpoints with some form of authentication, such as an API key. Without authentication, you’re leaving your API open to the world.
As a PSA (think it’s already been stated), Glitch no longer allows pinging services (such as Uptime Robot). If you would like to keep your project awake permanently, you will need to subscribe for around £7.80/month to enable “Boosted apps,” which keeps your app online and removes rate limits.
@SoulMonopoly I believe with noblox, the idea is that you regularly refresh the cookie to prevent it from expiring. You will need to store the resulting cookie in a file or database (SQLite is an option for this–it can be added to your project without the use of an external database hosting provider) as your app will need to use the new cookie when it needs to login.
You might set this up as a separate function which acts as a proxy for retrieving the cookie (from a file or database) or refreshing it after 24 hours (for example), and setting the noblox cookie.
This is somewhat true. So people are not the sharpest tool in the shed and they exported their cookie. Now, there is a new function call “setCookie” which would, set the cookie. You run that once and your cookie is set. As far as I know, it automatically refreshes the cookie.
Looking at the source code for noblox, it doesn’t appear to refresh automatically, but you could create a simple function for this no problem; either using some type of interval or cron job.
The documentation advises no less than 24 hours between refreshes, and that resulting cookies should be stored as you’ll need to reauthenticate using the refreshed cookie if the app is restarted.
It’s worth noting that it appears to be unknown how long cookies are valid for, so you may find that you could go months without needing to refresh–obviously you probably don’t want to wait this long, as if it does expire you will manually need to set the cookie again, so it’s best to do it in shorter intervals.
I have my ranking system connected to my bot. So I can run refresh cookie. I have a VPS I use to ping it whenever I need it so that I can refresh it. I would host it on my VPS but then I would have to expose the IP even with a custom domain. You can still use the old feature (not many people know). You would just have to find the setCookie file and find the code to ge tthe token and rewrite it to your own module, you can use it.
It is good for hosting. Cookies last quite a while. I have a bot that goes on and off for days and my cookie is still good. It doesn’t need to be up 24/7.
Yeah, I wouldn’t use glitch for this. They are making private projects only available to people with premium. And it’s not worth it to use glitch anymore.
Glitch: It is easy to use and very self explanatory, but has a 5 minute timeout
Repl.it: Again, very easy to use and you can use pingers like uptime robot, but anybody can look at your code, and if your token isnt in an environment file, then they can use it, and maybe harm something with it.
Just wanted to give the heads up that Glitch no longer supports new private projects for free users, so to protect your tokens, you should put them in a .env file and call them with process.env.variable_name.