Simple_oauth typed property errors after authentication with

Hi all!

I’m working on building a module for collecting soil survey data. I have a custom JavaScript UI that I’m now attempting to connect to the farmOS API via a Python API built with Flask (v3.0.0) and (v1.0.1). I am running farmOS v2. I can successfully authenticate and fetch a token, but when I attempt to do anything with the resulting client object, I get a nondescript 500 error in the browser and the following error in the Docker container log (see screenshot for complete stack trace):

Typed property Drupal\simple_oauth\Server\ResourceServer::$subject must not be accessed before initialization in /opt/drupal/web/modules/simple_oauth/src/Server/ResourceServer.php on line 97…

I get this error whether I run this from the browser or via a Python terminal, so it’s not an issue with Flask.

Here’s my code:

from flask import Flask
from farmOS import farmOS
import os

app = Flask(__name__)

def hello_world():
    hostname = "http://localhost"
    username = ...
    password = ...

    farm_client = farmOS(

    token = farm_client.authorize(username, password, scope="farm_manager")
    if token:
        return # this is where the error is thrown
        print("Authorization failed")

I’ve looked through the simple_oauth documentation, open issues, and just about any other resources I can come up with to troubleshoot this error but am now out of ideas. Any suggestions would be appreciated!

Thanks in advance for your help!

1 Like

Welcome to the forum @ktohalloran! :smile:

Huh. That is odd. I just tried the same thing myself, and I was able to run without an error. I tested it against a farmOS instance running v2.2.2 and one running v3.0.0. (Both were live instances with SSL enabled, so I did not use os.environ['OAUTHLIB_INSECURE_TRANSPORT'] = '1', not sure if that makes a difference here…)

I will ping @paul121 to see if he has any ideas. He has more experience with and Simple OAuth than I do…

@ktohalloran As a side note… I wonder if you could consider updating to farmOS v3.0.1. There are some changes to the Simple OAuth module (we updated from v5 to v6) in farmOS v3. I don’t know if they would help here, but in either case it’s probably best to get onto v3 sooner rather than later, before you get too far with your development and testing. Everything should work the same between farmOS v2 and v3, and is tested against v3, so it won’t require any changes to your code. And like I said it may not have anything to do with the issue you’re experiencing… so perhaps worth debugging this on v2 first before making the jump. But if we run out of ideas then that might be worth a try.

Ah so looking closer… it looks like the specific file that produced the error in your case (src/Server/ResourceServer.php) no longer exists in Simple OAuth v6…

So it may be worth seeing if you still experience the issue (or a similar one) in farmOS v3 + Simple OAuth v6…

This sounds really promising, thanks for noticing that! I actually did try to upgrade to farmOS v3 as a part of debugging this because I saw the update to the Simple OAuth version in the release notes, but reverted it back to v2 when I still saw the same error. That being said, since I was seeing the same error, I must not have correctly upgraded to Simple OAuth v6. So I’ll give that another try and update here with the result.

(As a related note, I noticed that the repo README still lists the supported farmOS servers as ^1.6 or 2.x so that may need an update.)

1 Like

Oh good to know! It may be that the same issue occurs, but it’s coming from a new file (if things moved around, but the logic is similar between the module’s versions). In either case, might as well try debugging on farmOS v3 since that’s the future! :smile:

Thanks for pointing this out! I opened a PR to change it to “^1.6 or greater”. :slight_smile:

Thinking ahead… if you do experience a similar error on farmOS v3 / Simple OAuth v6, my next line of questioning might be around your local hosting setup…

Did you set up a local environment exactly as described here?

Or maybe something more custom? Just want to narrow things down to figure out where to focus debugging. :slight_smile:

I haven’t tried testing this against a local instance, so I wonder if there’s something different in that regard. If you get the same/similar issue on farmOS v3 I will try it…

Thanks for opening the PR–my apologies for not thinking to just do that myself!

Ah, yes, my dev environment. I should probably have included a description in the initial post, but it seemed unlikely to be the problem and is quite the can of worms. That being said, it could be valuable info so here goes…

I think the most important thing to note about my dev env is that it’s built using WSL2 on Windows. My farmOS Docker instance follows the instructions above in every way except that I built it using WSL-based copies of Windows-based code on Docker running the WSL2 engine.

So if the issue is with my local env, it likely comes down to my use of WSL2, which has previously caused issues when trying to run Xdebug from PHPStorm due to the various requests being made between the Docker container inside WSL and the Windows-side applications like the browser and PHPStorm. The reason I don’t think this is the issue is because I get the same error regardless of whether I run the script from the Windows-based browser or a WSL-based Python terminal. In the latter case, it should be WSL talking directly to Docker, so little potential for blocked or misdirected requests/responses. I also don’t know why the requests to authenticate would succeed but following requests fail.

So all that said, this might be a difficult local env to replicate and I might just ultimately need a WSL expert’s advice. I’ll let you know what I see after the upgrade–fingers crossed that replication/WSL expertise won’t be necessary on this!

1 Like

Ok, I’ve upgraded to farmOS v3. The reason it didn’t work before was because I didn’t delete the www folder before building the new docker compose file and it didn’t update the composer.json file to match the new dependency requirements.

Once I figured that out, I then got “invalid client id” errors, which was fixed by installing the farmOS Default API Consumer module from the UI. Now I’m looking at a “Not Found for url: http://localhost/farm.json” error. Still not working perfectly, but this does seem to be making it farther along than before, which is good! I’ll keep troubleshooting, but please let me know if you have any thoughts about this new error.

1 Like

Ah ok, it was just an issue with the method. Fetching a resource now works as expected! :tada: Thank you so much for all of your help @mstenta!

1 Like

OK! Steps in the right direction! :smiley:

Ah yea, this module is optional in farmOS v3+, and not enabled by default: Issue #3256745 by paul121: Move default farm OAuth2 client to a separ… · farmOS/farmOS@c64247b · GitHub

Glad you figured it out!

Hmm farm.json was an endpoint in farmOS v1, but no longer exists in v2+. We moved most of the stuff that provided to the /api endpoint under

Oh wonderful! Glad it’s working for you now @ktohalloran! :smile: :rocket:

1 Like