I just updated the Moodle Desktop app to version 3.5 (through the Mac app store; running MacOS 10.13.3). When I launched it, it asked me to enter the site (I guess it didn't remember the site that I previous version had been configured with, which I thought was weird). After entering the site URL, I get our Shibboleth sign-in page, as expected. But it won't accept my credentials. I get a "The username you entered cannot be identified" error. I know I'm entering my credentials in correctly. And they work when logging into our Moodle site from a web browser.
I tried deleting the app and reinstalling. Didn't help. It won't accept my credentials (which are correct).
My credentials work fine on the iOS version of the Moodle Mobile app (v. 3.5).
Any ideas as to what might be going on?
Under mobile settings, "Type of Login" was set to "via an embedded browser (for SSO plugins)". It has been set like this since we began using the mobile app in August 2017. Accessing our Moodle site has worked fine in iOS, both before and after the mobile app 3.5 upgrade. It also worked fine using the desktop app, prior to the 3.5 upgrade (as I noted earlier). But since upgrading the desktop app to 3.5 (along with our recent upgrade to Moodle 3.4), the desktop app gives the "username you entered cannot be identified" error. So, with the "login via embedded browser" setting, we can log in on iOS, but not the desktop app (again, version 3.5).
I changed the login type setting to "via a browser window (for SSO plugins)". With this setting, I AM now able to log into our Moodle site on the desktop app (it sends me to my web browser to log in, then passes me back to the desktop app). Logging in on iOS also continues to work.
So the question seems to be why does mobile desktop app authentication work with the "via a browser window" setting, but not with the "via an embedded browser" setting? Prior to the desktop app update to 3.5, we were able to login via an embedded browser. I imagine there could be something about the way our campus authentication is set up that (now) prohibits login via an app's embedded browser. But I'm also wondering if there might be something different in the desktop app (3.5)?
I'm having the same issue with SSO log in not working on desktop version. How did you change the type of login settings to via browser?
Hi Brian and Anna,
sorry, I totally missed this discussion
The desktop app should work fine with the "via an embedded browser" setting. I just tested this and it worked fine for me in one of our sites.
Anna, you have some info about this setting in here:
Unfortunately, as I detailed above, we can no longer log into our Moodle 3.4 site with the latest version of the desktop app (I'm happy to hear it works for many others). We have it set to use an embedded browser. It does not work. Whether there is something different in our SSO configuration that is causing some sort of conflict with the new desktop app version, I can't say; and I can't do anything about. Just know that we ARE able to log into the latest iOS version with no problems. And, as I mentioned, if I change the mobile authentication setting to log in via a browser window, then I am able to log in via the desktop app.
I think there is something inherently different about the latest desktop app version that is causing this issue. It used to work (with the previous version)... it doesn't with the new version (all other things being equal). Perhaps this issue is local to our SSO implementation. But it's not worth investigating further on our end.
I'm sorry to hear it isn't working. When we upgraded the app to 3.5 we also updated the Electron version (the framework we use to build the desktop apps). This update forced us to change a bit how SSO works with embedded browser, I guess that's why it was working before but now it doesn't.
What happens after you authenticate in an embedded browser in your site?
After the user authenticates in the embedded browser, the site should redirect him to the launch page, and that page should display a message saying something like "Click here if the app does not open automatically". The app should detect this case and close the embedded browser, authenticating the user.
Hi Dani --
I detailed what happens in my initial post. I launched Moodle Desktop on my app. I enter the URL for our Moodle site. This opens our SSO login page (in an embedded browser) where I enter my credentials. I enter my credentials on our SSO login page, and it returns this error: "The username you entered cannot be identified." I entered the correct username and password. I've attached the error I see on our SSO login page.
I hope this helps. Thanks... Brian
Hi Dani --
I downloaded the new version 3.6 of the Moodle Desktop app (for Mac). I still can't login -- I get a username/password error (like the screenshot I attached in a previous message) -- even though my credentials are correct. We're now running Moodle 3.5.
we've been investigating this issue but we haven't been able to identify a possible cause.
Do you know if this is happening to other people?
Have you tried with the Moodle Desktop for Windows and Linux, using your credentials?
Have you tried copying and pasting the username/password, and entering them manually?
Do your username or password have any special character that can be affected by the page codification? Like a Ñ, ç, ô or ü ?
Hi Juan --
Thanks for getting back. I am entering my credentials in correctly. Others here also report receiving this error. That's not the issue.
What I described last year (in earlier posts) when Moodle Desktop 3.5 (when we were running Moodle 3.4) came out is still happening with v3.6 (we're now running Moodle 3.5). Mobile authentication login type is set to "via an embedded browser (for SSO plugins)" so the embedded browser window pops up. When I change this to "via a browser window (for SSO plugins)", the Moodle Desktop's embedded browser still pops-up -- my web browser does not launch. Last year I reported that changing the login type to "via browser" did cause the Moodle Desktop app to use the browser and then did work. Now, however, this setting doesn't appear to change the login type -- no matter what it's set to, the embedded browser still pops-up (and the login fails).
I haven't tested the Windows version with the Moodle Desktop 3.6. The problem I reported last year as also seen on the Windows app. I doubt I'll see anything different.
I've seen a review in the Mac App Store that details the same error I'm seeing. On this thread, someone else also reported the problem last year.
Perhaps a change was made in how the Desktop app handles this that some SSO implementations don't like. Or maybe only the SSO implementations have changed in some fashion, and the Desktop app is still doing what it always has done here, but now the SSO implementations don't like it. The result is the same.... we can't use the Desktop app at my institution.
I hope this helps. Thanks... Brian
I've been investigating this issue and I've found the cause of the problem. It seems your SSO is performing a redirect when sending the credentials, and the app doesn't support redirects (the parameters are lost when doing so), that's why it isn't unable to validate the user.
When sending the form, the data is sent to the URL:
and then it's redirected to:
In this redirect the username and password are lost.
I opened an issue to restore the SSO authentication in the system's browser in MacOS apps:
Unfortunately there's nothing we can do to fix the redirects, so if you want this to work in the embedded window you'll have to remove this redirect.
Hi Dani --
Thanks for the update. I'm happy to hear that you've discovered the problem. But it's not clear to me whether any fix to the app will address the problem I see when authenticating with our SSO. If, after the fix, we still would need to change how our SSO works, I can't see this happening. I seriously doubt our campus IT is going to modify the way our SSO is configured.
Hi Dani --
That's what I thought. Thanks for the update. It might be a good idea to add a note to the desktop app documentation about this redirect issue, and that some SSO implementations may not work with the embedded browser setting.
I updated the docs in here: