A problem with openid connection #479
Comments
Tracking is not related to login. Once the user has consented, tracking will start. The login only affects the ability for the data to be pushed to the server.
This is almost certainly the error, after we log in, we call Can you look at the e-mission console logs to see what the 500 error is? |
|
@shankari thanks:-) |
|
There is another error here seeming to point to a token expiry date but may be it's unrelated (usercache/get not profile/update): |
This is almost certainly it. The error is For some reason, the user token is not filled out. This could either be because the token is not generated properly OR because the message is not formatted properly. We saw the message formatting error in the UTF-8 issue and added some additional logging to debug it (#333 (comment)). Can you re-enable those logs and see the raw message so we can rule out formatting issues? |
|
Hi @shankari |
|
I suppose the "é" found in the logs comes from "décembre" (december), not from the user name or login because they use a login without any accent... |
I am not convinced that the problem is in fact with UTF-8. It is just that we added similar logging in the UTF-8 case. |
|
In the UTF-8 case, the error was while parsing the body into JSON, which is why we were able to see In this case, the body is blank This is consistent with an error in composing a message on the phone. Do you see a similar error for If it happens for both, the error may be in retrieving the user token (so actually with openid). |
|
Hi @shankari I have this error for a few /profile/update (and nothing with profile/create, which is much rarer), where there is no UUID (but not "é" error or blank body) : The 'trying to log unicode character é' log is not an error actually, it happens only when starting the server (it is located in the main part of cfc_webapp.py file and I don't see any reason why we added this logging.debud instruction!) Here are a few more examples of the 500 errors I have with the user are for profile/updates : Note that I suggested the user to install the embase app with from your damajash site, but the server seems to be down, so I suggested her to test the e-mission app from the Play Store. I will tell you if it works! |
|
@PatGendre The update body seems to be valid here - as expected, the body contains the push notification token, the current platform and the sync interval and I don't see any unusual characters in it. What it doesn't have is the I understand that they can't get the client logs if the onboarding does not complete. Since they are on android, can you give them a custom apk that has the update call commented out? You won't be able to demo the push notifications, but they can move beyond the onboarding and email me the logs for debugging.
The damajash site was for a live demo, so only the polar bear version was updated. You have to refresh the screen until you get to the polar bear to get a working version. If you use the other screens, they will try to connect to a non-existent server. |
|
@shankari
Ok thanks |
Actually, you don't even need access to the keycloak logs - if you generate an apk without the update step as I suggested above, they will be able to get past the onboarding and I can look at the error from the app side. |
|
Hi @shankari , we could generate an apk which bypasses the login so our user could try use the application. I am not sure what we can find, there are some 401 and 500 errors but no auth error because the user does not log in any moren with this apk. May I e-mail you the usercache logs sqlite DB so that you can have a look? |
|
@PatGendre yes please. Let me see what is going on. |
|
@PatGendre does the apk bypass the login or only the You want to keep the login in place (since |
|
@shankari yes I think the patch bypasses the login altogether and I will ask to modify the patch. |
|
@shankari Hi, Tristan updated the patch (commenting out line 71); In case it might be useful I e-mailed to myself logs and usercache of the patched app, which I've installed for the week-end. |
|
Hi @shankari
I created a test user, and when I connect to the app with the test user on my phone, it works fine.
Any idea for this behaviour? |
|
@PatGendre can we focus on the most obvious error:
Let me see if I understand this correctly.
Can you generate me e-mission phone logs from both you and Florian, for this scenario, starting from a freshly installed app? We can then look at the logs side by side and see the differences. Because this is super weird. If the login works from your phone and not from Florian's phone for the same user then there must be something wrong/challenging about the configuration on Florian's phone, similar to the original CEREMA testing. If you send me the test user credentials and the link to the FabMob app, I can also try to install and login from my phone and see if I can reproduce. |
|
Thanks, i sent you the credentials. |
|
Searching for this error, I found a similar issues reported by an automated testing framework. cypress-io/cypress#3119 Consensus is that:
Is there a difference in the browser that you and Florian are using to finish the authentication (e.g. chrome v/s firefox)? I will try this out, but we may have to look at the keycloak logs at the end. |
|
Looking at the keycloak code (yay open source!), it looks like this error is related to an invalid code
And poking around for other instances of In this location, in addition to generating the error, there is a challenge which I think means that the user will be asked to verify the email. But in this case, And it is because there is a mismatched cookie.
There are a couple of other error locations, but they focus on handling an error generated from somewhere else, and I don't want to go down the rabbit hole yet. Given this initial search, I wonder if there are some issues with cookies on Florian's phone. Does he have cookies turned off in the browser? Is he using a different browser? |
|
Thanks for your inquiry ! I will forward your questions to Florian and keep you informed. |
|
@shankari for Noémie at least, it appears that chrome was deactivated, and that this caused the problem. With the chrome app installed and activated on her phone, she could connect with her credentials :-)) thanks a lot for having identified the browser as the root cause ! I'll tell you when I know for Florian.... |
|
Hi Shankari, thank you very much for your support. Knowing that doesn't allow me to be able to use the app as the embedded webpage is only opened with Chrome in the app. Moreover, I must not be the only one to face this issue. |
|
|
From the AppAuth docs, it is possible to select the browser used for authentication, including the version. If we can figure out a reliable browser configuration, we can specify it as part of the auth config. |
|
Hi, I'm Noémie :) I've tested on two devices, one with Firefox (68.4.1) as default browser, and the second one with Firefox Klar as default browser. |
|
@overflorian so it looks like there is something specific to your Chrome since the same browser seems to work for both @PatGendre and @nlehuby.
|
|
if you plan to build your own app, and are worried about this affecting your end users, you could use one of the other authentication mechanisms, or maybe implement and contribute an integration with Auth0 which claims to have "solved auth" :) |
|
Chrome 57.0.2987.132 on one device, and Chrome 79.0.3945.116 on the other. |
|
@overflorian, I also wonder if the error this time is due to cached cookies from your previous login. Can you try clearing your cookies and see what the behavior is? Also, if you do want to continue using OpenID Connect, you could add a message to the login screen about trying different browsers until one works. Not sure if that is optimal from a UX design perspective, but this also seems to be a corner case wrt auth since chrome works for everybody other than @overflorian |
|
@overflorian so the problem is almost solved now, does it work you now, or not yet? maybe after clearing the cooking? @shankari thanks again, shall I update the doc for this issues somewhere e.g. in "troubleshooting the app"? It is not clear to me if this likely to occur again as it concerns only the openid auth config. |
|
@PatGendre I think it would still be useful to figure out why it is not working for @overflorian in his version of chrome. Once we know that, I think it would be useful to have some details in the openid auth section of the documentation. As I said earlier, it would probably be useful for deployers who use openid connect to put in some basic troubleshooting information into the sign in screen. |
Hi @shankari we have 2 new users who installed our fabmob app but they cannot access to the app. They created a fabmob account via our openid keycloak server, and this worked.
But when they try to log in, they get rejected with "an error occurred" from the log in screen, and get forwarded back to the consent screen so they are unable to use the app (and to send the app logs/usercache).
However they get from time to time a e-mission trip-end notification so may be the tracking works?
They tried to connect from their app with the credentials of the new user, but they failed, too.
They can access to the e-mission homepage from a browser.
They are on Android, resp. with a OnePlus 5000 (android 9) and a Motorola moto G play (android 7.1.1), so it is not likely that this due do the device.
In the apache2 reverse proxy logs, I see a 500 when they try to go the profile screen:
grfmapfabmob:443 IPaddress - - [12/Dec/2019:18:51:18 +0100] "POST /profile/update HTTP/1.1" 500 5071 "-" "Traceur de mobilit\xe9 FabMob"As a test Yann and I created 2 new users and it worked. Other (real) users have created recently an account and installed the app and it worked.
Currently we don't have access to the keycloak logs (we leaved a few messages for the keycloak admin but he has not responded yet).
We don't find the cause so I create this issue... Thanks in advance if you have any clue!
The text was updated successfully, but these errors were encountered: