I’ve just tested again incase my memory was mistaken, but I can confirm that
OAuth2 does not require SSL.
The endpoint looks the same with http:// or https//
I wonder about the slashes in the path being in 2 different directions?
Don’t have any experience of Windows Web servers but it doesn’t look right, perhaps a relative path rather than a windows C:/ root path is needed there?
I think before trying the python script again. Seeing RSA keys in those files is a must, also need to be able to navigate to the endpoint in a browser, (If it says invalid client its normal as parameters aren’t passed)
But good luck with it.
Edit:
Just one more thing, does generate keys button return any errors?
Oh, I have a theory, but you probably need to wait for the devs to come back to this conversation, they are at a conference for the next few days so might not be as active as normal.
I wonder if this is Windows related? I know Windows is not the recommend platform for farmOS. I wonder if the script to generate the RSA keys has a dependency that is generally found in Linux but missing from Windows or perhaps would just need some modification.
OK, I’m definitely leaving it here as I’ve probably already wondered too far down the wrong rabbit hole.
The only thing I see, Keys are generated by PHP so not really a Linux Windows thing but there seems to be a filesystem check which I suppose windows may fail.
perhaps this could be worth a read.
I’m seeing warnings about my private key file permissions. What should I do?
The upstream OAuth library checks the private key’s file permissions by default. This is suitable in certain server configurations, however in some modern environments (e.g., containerized workloads) where secrets are injected into the environment and owned by a user different from the web daemon’s run-as user, this is a false-positive. In these scenarios, you can use the Settings API to set the value passed to CryptKey::__construct() for checking the file permission:
In settings.php: $settings['simple_oauth.key_permissions_check'] = FALSE;
Also worth checking https://geosrv4/admin/reports/dblog for any errors if you have not already. especially immediately after trying to generate keys.
Huh that is strange. Worth noting that the “Generate keys” button is just a handy helper, but you can also generate the keys manually and put them into place. This command will do it (on Linux, not sure Windows… but if you can do this on a Linux box and copy the files over that should work).
Go to https://geosrv4/web/admin/reports/dblog and see if there are any relevant errors in the log that offer more details. Sometimes this log will contain more information than what is sent back to the client.
Just to go back and check some other assumptions: when you navigate to https://geosrv4/web/admin/config/services/consumer you see a “Farm default” client with a client_id of farm, correct? Have you made any changes to the configuration of this client?
You don’t need to set the redirect for password authentication, but it shouldn’t stop it either.
Are you getting any page when you use your browser to view https://geosrv4/web/oauth/token now? It should return r a client error message when no other parameters are passed?
It does look like the farm client has been edited… In a default installation the “Scopes” are empty. Can you paste a full screenshot of the client configuration so we can compare it to the default and see if anything else is different?
Also, the logs will probably be the most useful, if you can paste those:
and when i run curl
curl -X POST C:\Users\Administrator\Desktop\farmOsScrips> curl -X POST -d “grant_type=password&username=Testuser&password=Geo@Greenhealth&client_id=farm&scope=farm_manager” https://geosrv4/web/oauth/token
The website encountered an unexpected error. Please try again later.
@silverlynxconsulting OK it sounds like a lot of this is coming down to the interaction between Windows and the OAuth2 libraries that farmOS uses. I’ve never tested these things on Windows myself, so this is the first time we’re thinking about it.
Two choices here: 1) continue down this path to figure out (and document) how to make this work on Windows, or 2) you switch over to Linux (or Docker in WSL on Windows).
Which is perhaps a question for you @silverlynxconsulting: how much do you want to help debug something vs how important is it to just “make it work”?