Oauth2 does not seem to work /signin/success?jwt=very_long_jwt_token returns HTTP 400 saying that jwt is missing (but is not as you can see)

[distributev]

Hello,
Thank you again for scoold it loooks as a useful software.
I'm trying to configure scoold with Oauth2 using a self hosted oauth server. I believe I have correctly configured things since I am able to see many things related with oauth flow working -

However just after login I get an HTTP 400 error and the scoold DEBUG logs show

2023-11-29 15:25:27 [DEBUG] Resolved [org.springframework.web.bind.MissingServletRequestParameterException: Required request parameter 'jwt' for method parameter type String is not present]
2023-11-29 15:25:27 [DEBUG] Completed 400 BAD_REQUEST

however the URL of the browser for the page which show this error contains a the jwt get argument like this

https://www.example.org/qa/signin/success?jwt=very_long_jwt_token
Here is how scoold-application.conf looks

#############  CORE  #############

scoold.para_access_key = "app:scoold"
scoold.para_secret_key = "123"
scoold.para_endpoint = "https://para.example.org"
scoold.app_secret_key = "456"


scoold.host_url = "https://www.example.org"

#############  MISCELLANEOUS  #############

scoold.autoinit.para_config_file = "/scoold/para-application.conf"

scoold.context_path = "/qa"
scoold.admins = "john06example.org"

####### OAUTH2 ##########

# minimal setup
scoold.oa2_app_id = "789"
scoold.oa2_secret = "101112"
scoold.security.oauth.authz_url = "https://oauth-server.example.org/oauth/authorize"
scoold.security.oauth.token_url = "https://oauth-server.example.org/oauth/token"
scoold.security.oauth.profile_url = "https://oauth-server.example.org/oauth/me"
scoold.security.oauth.scope = "openid email profile"

and here is how para-application.conf looks

para.root_access_key = "app:scoold"
para.root_secret_key = "131415"

[albogdano]

Are you sure that the value of para.root_access_key is "app:scoold"? That doesn't seem right - it should be "app:para" and a secret different than that found in scoold.para_secret_key.
There are no reports of this kind of issue which leads me to believe it has something to do with your configuration.
Try to trace the request using the browser dev console with "preserve log" checked under the Network tab.
The request flow should be something like this: Scoold login page > OAuth2 login page > Para /oauth2_auth > Scoold /signin/success

[distributev]

just tried with

scoold.app_name = "Scoold"
scoold.para_access_key = "app:para"
scoold.para_secret_key = "Dvf6aSnyCMNkcABGW9+aWmmm8I80gwVAcfc8RTBthEz8d7suTl59nA=="

in scoold-applicationc.conf and

para.root_access_key = "app:para"
para.root_secret_key = "Dvf6aSnyCMNkcABGW9+aWmmm8I80gwVAcfc8RTBthEz8d7suTl59nA=="

in para-application.conf

and I get the same

023-11-29 17:24:00 [DEBUG] Resolved [org.springframework.web.bind.MissingServletRequestParameterException: Required request parameter 'jwt' for method parameter type String is not present]
2023-11-29 17:24:00 [DEBUG] Completed 400 BAD_REQUEST

It is not very clear when to use app:scoold and when to use app:para and where in para-application.con and/or scoold-application.conf

[distributev]

The error is happening with signin/success?jwt=long_jwt_token in the browser URL

Here is a screenshot with devtools as you suggested

[albogdano]

So app:para is the root (system) app used by Para itself for keeping data about other applications. Scoold has its own app, usually called app:scoold and this is the main app Scoold works with. Do not put the secret key for app:para in your scoold-application.conf file.
The error is very unusual and my best guess is that it's cause by some sort of URL conflict because Para is hosted on the root path / and Scoold is hosted on the path /qa/. Also try with another browser without any extensions or blockers. Everything else seems fine in the authentication flow and the request itself is successful, up to the point it hits Scoold.

[albogdano]

Also, try changing the scoold.host_url to be the exact URL of your Scoold server including the context path /qa at the end.

[distributev]

Somehow I managed to get it working - I say "somehow" because it is not very clear to me what I did to get it working or why it was not working before - I believe that what I did just before getting to work is that I emptied the "data" folder and scoold recreated (what?! it's config?) once restarted - let me run it for a longer time, have it stopped/started couple of times without errors because I believe I saw it working before and then errors came back - at least now I will remember I can empty the /data folder when strange things are happening.

the app is useful, the architectures looks good at first sight with the backend "para" being separated (separation of concerns) and providing useful multi-tenant capabilities (besides other things) to scoold however, in practice, it adds a layer of complexity and moving parts when deploying the app - configuring each layer para and scoold separately then in the para config you can put configurations related with the "root" para app but also with the "child" apps - in the para documentation it mentions that but I did not see clear examples how to do that - then in the scoold docs it says something about the child apps in para but again is not giving a clear example how to do it - but then it says something "when you start scoold it will auto-create it's stuff in the para configuration" - at some point I tried to manually add the scoold app in the para.config but I did that in an incorrect way however when I started scoold it copied to /data the incorrect configs I added.

Then, trying to fix that, I corrected/removed lines from the para.config and left para.config almost empty but because the data folder was already populated the scoold app was not regenerating the new stuff - suddenly, once I emptied the /data folder and restarted the app, scoold recreated /data folder with the correct state.

Long story short I believe it could be useful if scoold + para could be bundled/deployed together like a single unit with para being "pre-configured" to work with scoold and this way to have scoold being started/deployed in a single run/step and with a single set of configurations inside the scoold-configuration.config

Now, with scoold automatically generating it's para configuration at startup time, it is kind of that however it is not exactly like that - the docs still mention para-configuration.config, users are still required to edit few things inside para-configuration.conf - most of the configuration is generated at start time unless you already have old invalid configs inside the /data folder and then, until you have the inspiration to empty the data folder, you could waste a lot of time looking why it is not working something which was supposed to work.

Having everything bundled/deployed in a a single piece would eliminate half of the moving parts.

[distributev]

Yesterday I tried so many things and I wasted a lot of time with the oauth2 issue that I actually forgot how I got it working :-)

Indeed I did go into some strange errors because of the double para/scoold configuration which I described previously and it could be beneficial to bundle para inside scoold such a way that the users will see and configure only scoold.

For the specific oauth2 issue the culprit was the nginx reverse proxy which was droping the jwt token from the url.

The solution was to modify the "location" configuration for the /community/qa path inside the nginx reverse proxy configuration such a way that the jwt token is preserved and passed further to scoold.

[albogdano]

Thanks for the useful feedback regarding the initial experience with Para and Scoold! I will try to simplify the deployment process further and probably add like some sort of embedded Para service in Scoold as a new default in the future. You have very valid points since most of the deployments are single-tenant Scoold servers that use a single Para app (app:scoold).
The whole initialization process with the creation of the root app and the child app for Scoold is already automated with the auto-initialization feature in Scoold and only requires a single line of configuration:

scoold.autoinit.para_config_file = "/scoold/para-application.conf"

Then you first start Para, it initializes itself and creates the ./data folder along with the root app. Finally, you start Scoold and it reads the Para config file and tries to initialize itself also. If that succeeds, you have everything working properly.
So the idea is to skip the manual creation of child apps altogether.

As for the OAuth2 error - I was pretty sure something like that was happening and my next question would have been if there were any load balancers in front of Scoold. Anyway, there is a basic nginx configuration in the Scoold README which has been tested to work. Some people also forget to make nginx pass headers like X-Forwarded-Proto which are sometimes necessary for correct operation.

[distributev]

You can close this it was the nginx reverse proxy configuration. The nginx configuration issue was in the same time with other para/scoold configuration difficulties and this made things more difficult to debug.

The documentation mentions para-application.conf so this is the reason I started to mess with that I assumed that, if para-application.conf is mentioned into the readme docs, things should be configured there. Then I landed to the https://paraio.org/docs/ website and was reading about child apps and read about the root app and about the scoold app and I assumed I need to do that (manually) otherwise why para-application.conf would be mentioned in the docs? At that point the /data folder was already created with wrong configs - then I read will be populated automatically upon initialization and got a hint that if I keep para-application.conf at minimum and empty the /data folder things will autoconfigure - but then why the word "Para" appears 174 times in the readme.md if Scoold auto-configures itself in regards with Para and I have nothing to configure in Para?

Having "Para" bundled + auto-configured inside Scoold without the users even having to be aware about Para's existence will simplify the Scoold deployment.

Whoever wants / need "Para" to be separate has https://paraio.org

[albogdano]

Thanks again - noted! I will reduce the number of times Para is mentioned in the README and probably remove the mention of para-application.conf except for the Docker stuff.