I just had a discussion with @hhoechtl regarding Google Authentication.
We currently have an Oauth redirect mechanism based authentication in the Neos.GoogleAnalytics package.
And OneDrop recently released a package for connect with the Google Indexing Service (https://github.com/1drop/Onedrop.GoogleNotify) which requires storing a json with a set of Google Service Account credentials.
Now I’m currently building a Search Console integration into my Yoast package which also needs authentication.
Therefore we agreed, that it makes sense to create a Google Auth package that provides a storage and some basic mechanisms which all Google related packages can use.
The first method would be to add the JSON config via a command. But I also think about having a backend admin module where you can upload and check the credentials.
As the Analytics package is in the Neos namespace, I would have to put it also into the Neos namespace.
First question: Any objections to putting it into the Neos namespace?
I think I wasn’t clear enough what I want to achieve.
Main thing is to simplify and unify the way packages interact with the Google API.
And the package should contain the least amount of features to be easily maintainable:
Provide dependency to Google API
Simple way to give credentials to Google Client (via environment or stored credentials)
Client factory that is well configured for Neos
Psr logging & caching configuration for Google Client
Shell commands to test and check API
Being able to get an overview which packages use the API
Prevent packages from using different API versions and doing the same thing in different ways
Hi!
But we already have Flowpack.OAuth2.Client? Its code is rotten and needs to be re-written on top of some other 3rd-party OAuth implementation, but I think we should just release a major version of that package with the re-written code, rather than creating yet one more package.
I actually want to get rid of the OAuth part as it would only be needed if you want to access user data via the Google Services which is not needed in Neos backend concerning use cases.
Currently every Google Api integration would need ~10 files to prepare everything in a nice way to access the Google Services. The idea is to get rid of that and only need bit of config and you can use the Api in your own package.
This way it would also be possible for the admin to have an overview how the Api is used and how to configure the permissions on the Google side easily.
From what I know I don’t think the OAuth2 client would help there.
Yes, when your factory creates a new client you can tell it to look for environment variables. But this is only the path to your credentials.
Storing the credentials has the advantage that it’s easier for handling multi sites and the are enough environments where the environment variables are a bit of a hassle to set up.
Of course the package can check for the variable and then just use that.
You still need the factory method to generate the client, configure logging, configure caching, etc…
My 2 cents:
I think configuration backend modules are not the Neos way and should be avoided, if such configuration values are also shipable with a deployment. And for credentials, even better getting them from environment variables.
