Jun 09 2020 12:30 PM - edited Jun 09 2020 02:05 PM
I use HashRouter in my React app ( hosted on IIS). Noticed that Edge browser somehow loses the hash path (#/rest of path) when it returns from the server after authentication. So user ends up on the main page. However, it works as expected(retains hash path) on the consecutive try, or if the browser has the application open on another window or tab.
Not sure where to look for answers
Jun 12 2020 10:41 AM
@vindiW Thanks for reaching out. It sounds like this might be related to a known issue in Chromium code, which there are a number of open bugs for:
Jun 12 2020 10:51 AM - last edited on Jun 12 2020 11:20 AM by Deleted
Jun 12 2020 10:51 AM - last edited on Jun 12 2020 11:20 AM by Deleted
Solution@Deleted - That's an impressive list of URL Fragment related issues, but none of them are likely relevant here.
@vindiW - You can watch your network traffic to see what's going on, but the most likely explanation here is that this is related to behavior of your your authentication provider. In particular, if you have a URL fragment that goes through a set of HTTP/3xx redirects, that URL fragment is meant to be preserved, and it is, within modern browsers. However, if the server returns a HTTP/200 response (e.g. because it wants you to enter your credentials), then when it redirects back to the relying party website, that URL fragment is not automatically carried through.
If you'd like, I can take a look [personal information removed by Mod] at a NetLog for you (https://textslashplain.com/2020/01/17/capture-network-logs-from-edge-and-chrome/) to confirm.
Jun 12 2020 11:00 AM
@Eric_Lawrence Yes. You are exactly right about, that URL fragment being preserved. But it seems the the hash fragment is not preserved or ignored during the redirect( after SSO) as the auth token is attached to the hash of the URL(this is what I read). So I found a workaround to preserve the hash fragment (append as a query param) on client side and reattach it to the returning URL.
Thanks for your time and information
Jun 12 2020 11:05 AM
@Deleted Thanks for getting back.
I found the issue and it is related to the SSO and seems losing the hash fragment of the URL is common issue. the browser however preserve it along with all other URL fragments, but the server that handles authentication seems to be removing it. I found a workaround to fix this temporarily.
That list is definitely worth saving though, for future references
Thanks for your time, appreciate it
Dec 04 2021 12:43 AM
Well, sometimes switching from one tool to another is a necessity for a company to continue to grow and offer better services to customers.
Dec 04 2021 02:02 AM - edited Dec 04 2021 02:02 AM
In general, this is not difficult if the company is working with a reliable developer. Therefore, when questions like flutter vs react native arise, there is always an opportunity to first get acquainted with the available information on the Internet, and then turn to a specialist for help in order to get an excellent result for work.
Jun 12 2020 10:51 AM - last edited on Jun 12 2020 11:20 AM by Deleted
Jun 12 2020 10:51 AM - last edited on Jun 12 2020 11:20 AM by Deleted
Solution@Deleted - That's an impressive list of URL Fragment related issues, but none of them are likely relevant here.
@vindiW - You can watch your network traffic to see what's going on, but the most likely explanation here is that this is related to behavior of your your authentication provider. In particular, if you have a URL fragment that goes through a set of HTTP/3xx redirects, that URL fragment is meant to be preserved, and it is, within modern browsers. However, if the server returns a HTTP/200 response (e.g. because it wants you to enter your credentials), then when it redirects back to the relying party website, that URL fragment is not automatically carried through.
If you'd like, I can take a look [personal information removed by Mod] at a NetLog for you (https://textslashplain.com/2020/01/17/capture-network-logs-from-edge-and-chrome/) to confirm.