Hi Vincent, Thank you for your quick response! I understand your concern regarding the risk of old, lingering cookies. However, the issue lies in the resulting dead-end for the user flow. Users encounter a slightly confusing screen that restricts their ability to proceed, leaving them with limited options like typing in a new URL or using the browser's default functionalities to navigate back. In some cases, this confusion has led individuals to interpret the screen as a prompt to change their password. Increasing the time would ofcourse help in some of the situations, but not for all cases. Also in regard to the related issues (I mentioned in my original post), it might be a solution to create a customizable page for this case. Check if there is still a cookie and otherwise redirect to the custom page. On the custom page we can explain to the user that the login process took to long and they have to retry it, via entering the URL of going back in the browser. Ideally, it would be p
@Vincent Doppenberg Thanks for your response.It is a valid case that users can sign in with their e-mailadres? Didn't know about that feature, but that might give some issues indeed. Since there could be multiple accounts..
@Anne Buit Do you have an expected releasedate? Since we keep getting more users who are experiencing this issue… They cannot solve it themselves…
Hi Mark, I deleted the complete application folder (with help from Boudewijn) and the issue is still there. I use the TSF_CS.exe.
The screens we saw it on were not that complex. We just upgraded to the newest version and will keep an eye out if the issue is still there.
Hi Mark, I can recreate it any second you want😉Maybe we can have a meeting and I can show you the problem? I used my files to upgrade the application for other people and there it works with icons. So I don't think its the files.
Update: It is only the case for SVG's and the PNG's still work. I can open the icons and see them wen I click on the grey box
@Vincent Doppenberg Do you have time for a quick call? I think it will be much faster to show you the issues? It is only since the last upgrade of Indicium. Before that we didn't have this problem.
To answer your questions: It is the same user i'm using. The bottom one is bearer token The top one is basic auth. The error with bearer token is 162ms, the succesfull call with basic auth is 129ms. We just upgraded to the newest version of indicium, since then we have this problem. The version before that (that is still running in production) doesn't have this issue.
The queries are identical in the dbEventLog for that user
Development: 2024.1Production: 2023.3If I make the call directly using the IP address, then the call succeeds in both cases
@Vincent Doppenberg One control question before we change configuration. If I keep the cookie in postman, (the cookie from basic auth) and then run the call also with a bearer token, the correct response is given instead of a 502. Is this also in line with your expectation? so reproduction:First run a succesful call with basic auth Run the same call without deleting the cookie and do it with a bearer token. Get a normal response. If I delete the cookie from the basic auth call, I get the 502 again.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
