The system config is OpenMRS core 2.6.0 / Refapp 2.13.0-SNAPSHOT / Ubuntu 22.04.1 LTS
The effort has been to install oauth2login on a system with the above mentioned specifications. The below error (500–Internal Server Error) is seen after the installation of the module:
org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [webModuleApplicationContext.xml]; nested exception is java.io.FileNotFoundException: class path resource [webModuleApplicationContext.xml] cannot be opened because it does not exist
I don’t think we’ve ever tried it yet with Core 2.6.x. Not that the error message that you shared necessarily hints at this, but it would be worthwhile trying the setup with a released Ref App (say 2.12.0) and a released version of the module (say 1.1.0).
Please let me know if I need to try a different version of Core. What would be the latest stable versions of Core and Ref App that would work well with OAuth 2 Login (1.1.0)?
OAuth 2 Login really requires the oauth2.properties file to be there btw, and configured with URIs pointing to the various needed endpoints of the IdP.
Did you go through the README and set everything up accordingly? There are whole guides for Keycloak and Google API. The latter can be convenient to test things out.
@nischith / @mksd - unless things have changed in the last year (and from github it does not appear that they have), in my experience this module is not yet compatible beyond OpenMRS 2.3.x, due to upgrades to the Spring Framework in core and the dependence that this module has on specific versions of Spring due to the utilization of Spring Security.
Right now I am in the middle of an ongoing implementation. I really think this module adds a lot of value and makes the login process efficient. Would you advise downgrading to OpenMRS Core 2.3.x to incorporate this module? or are there any suitable alternatives?
Also, it would be good to know if there are implementations out there making good use of this module.
Also as soon as we have released Ref App 3.x we will want to bump Core to the latest snapshot. At that point we will face and fix the issues that arise against Core 2.6.x since they will show up on the bleeding edge Ozone Pro.
The stack trace points to this line at the moment when fetching the user info JSON from Google API. And basically this request gets denied.
Difficult to say without following how all this was configured, unfortunately it is also possible that things changed on Google’s end since that guide was first written (mid 2019).
As you rightly pointed out, it looks like that now, an additional step is needed at Google’s end that was probably not required earlier.
The additional step that is needed is:
App verification (this needs to happen before configuring the consent screen)
Basically, only verified Domains/ Apps are allowed to access the services and all other additional details are clearly mentioned in the new setup pages.