?i=1 remove "hash(#)" from url

[bakomon]

Reproduction steps:

• Open https://bakomon.epizy.com/#description
• The page reload with the ?=1 suffix & hash “description” removed

Any solution for this?

[Frank419]

See

Why do I see ?i=1 at the end of a URL

When you first open your website, you may see the extra characters like ?i=1 at the end of your URL. This article explains more about what causes it, and what you can do about it. What causes the ?i=1 suffix? This extra URL parameter is caused by a security system we use to protect your website. This security system ensures that your website can only be accessed through regular web browsers. What does the ?i=1 suffix do? The ?i=1 suffix is a counter. When you first load your website, some Ja…

This is part of our security system so sorry.

[bakomon]

I know “?i=1” is part of the security system and I’ve read about it.

But, why remove hash(#) from url?

Why not just add the querystring parameter “i” and keep the other url parameters?

@Admin

[KangJL]

@bakomon

• Open https://bakomon.epizy.com/#description
• The page reload with the ?=1 suffix & hash “description” removed

I see this

What issue?

Stop pinging admin, it’s annoying

[SpookyKipper]

The #description element id is actually removed by the system on first load, you probably loaded it once before

[Admin]

I don’t think that it’s possible to fix this, not without us making substantial changes to how the system works.

When a new browser loads the page, it’s presented with a Javascript challenge that will redirect you to the “same” URL with the ?i=1 suffix. The URL you’ll be redirected to is generated on the server. It does properly maintain the URL path and any query string you were passing along. However, browsers do not send the URL fragment to the server, so there is no way for the server to know if there is a URL to be included, let alone what that fragment should be.

Hypothetically, it could be possible to generate the redirect target URL from Javascript instead, which would make it possible to include the URL fragment. But that requires substantial changes to how the code works, so we can’t do that just like that.

[bakomon]

browsers do not send the URL fragment to the server

How about sending full url as a string to server, then parsing it on server side?

[Admin]

I’m not sure how you think that should work exactly.

Right now, in the normal situation, a visitor first visits the site for the first time, e.g. http://example.com/forum/topics.php?topic_id=1234#post5. In the access logs on the server, you would see the requested URL as /forum/topics.php?topic_id=1234, because the fragment is not sent to the server.

Because the visitor have the security cookie, the server responds with the challenge Javascript code, which contains code to redirect the visitor to the URL it received from the client, which is http://example.com/forum/topics.php?topic_id=1234.

While hypothetically it’s possible to send the URL fragment to the server from the challenge code, it’s too late, because the redirect URL has already been set. And doing another request to determine it would only make the process even slower.