I understand the fact that we’re using Free Hosting, which involves an intrusive security system, but does aes.js have to go THIS far!?!? I haven’t received my eu.org domain yet, so choosing a new free hosting solution is difficult!
My JriMail client, which relies on ?[code]= in the Client’s browser to transfer necessary information to securely connect to the JriMail Client, is being stopped by aes.js! The layer between the login screen and the JriMail Client is transfering the data normally, but the JriMail client can’t read it. Why? Oh, it’s because ?i=1 no longer persists! It looks like ?i=1 needs to be renewed EVERY connection!
It used to persist, which was a benefit for my JriMail Client! Server-side verification is still underway, but I can’t go full-on server-side!
What do you mean by the ?i=1 not persisting? Does it increment on every page load? Or is it not working cross domain? Because if it’s the latter, that’s how it has always worked.
My site increments the ?i=by one, reaching three before erroring out.
Other Information
I have JS and Cookies enabled, but this issue persists. I tested my site on multiple devices, multiple ways, but the issue persists. I’ve even disabled the (weirdly enabled by default) 3rd-party-cookie block on Chrome, but it still persists.
Blocking third party cookies should not be an issue, because the security cookie is not a third party cookie. As long as you aren’t block all cookies, you should be able to access your website.
Also, I moved the posts from the other topic here. If the topic specifically talks about the security system in combination with Cloudflare, and you’re not using Cloudflare, then that topic is not related to your issue.
It’s been ~24 hours since this issue occurred, and now this issue has disappeared for me. I don’t get what happened yesterday that caused this weird error, but I’m happy to see it was only me experiencing this issue (since I have a good amount of people using my services).
I thought it was talking about aes.js, apologies for that!
EDIT: My Network Provider’s router had a cache system enabled, which seems to have caused this issue. I had to set it to exclude caching my sites so that I don’t experience this issue again. IDK why disabling cache on my network router solves this issue, but it does. (Maybe AES.JS was never updated when it was improved, and this issue was triggered.)