Allow base64 encoded credentials in URL #409
Labels
api: bigquery
Issues related to the googleapis/python-bigquery-sqlalchemy API.
type: feature request
‘Nice-to-have’ improvement, new feature or different behavior or design.
Comments
4 tasks
|
This is a reasonable request. I'd like us to be flexible and allow user-based tokens such as https://github.com/googleapis/google-auth-library-python/blob/fffe3d01c4b397603639322bbd0ba062c03dacb7/google/auth/_default.py#L82 but starting with encoded key files is a good starting point. |
|
Thanks. I wasn't aware of other token-based approaches. I'ld take a closer look. |
gcf-merge-on-green bot
pushed a commit
that referenced
this issue
Feb 17, 2022
Fixes #409 🦕 To enable credential information to be included in the connection URL, for cases where you don't have a credentials file locally on the client, I propose the `credentials_base64` parameter. It requires that the user have encoded their credentials JSON file using a number of techniques like `base64`, or `openssl base64`, or `python -m base64`, or www.base64encode.org. I have used nox to run unit and system tests for Python 3.6 - 3.9. I'm tracking down a separate issue with my computer for why 3.10 tests did not run. - [x] Make sure to open an issue as a [bug/issue](https://github.com/googleapis/python-bigquery-sqlalchemy/issues/new/choose) before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea - [x] Ensure the tests and linter pass - [x] Code coverage does not decrease (if any source code was changed) - [x] Appropriate docs were updated (if necessary)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
I'm using Intake to build a catalog server where the server stores the credentials and does not require our users to have the credentials on their clients. When using the Intake server with
direct_access: allowthe current scenario creates the SQLAlchemy engine by forwarding the connection string from the Intake server to the client. The alternative isdirect_access: forbidwhich means that the Intake server connects to the database with its stored credentials json file and then forwards the data to the client. This creates a memory bottleneck in the Intake server. Thedirect_access: allowmethod forwards the connection string to the client to make the connection by passingcredentials_path=/path/on/server/creds.jsonmeans that the client cannot authenticate.Describe the solution you'd like
I'd like to have the full credentials inlined into the URL to enable our Intake server with
direct_access: allow. While in a general case this may be less than ideal since this catalog server is forwarding secret information to the client, we deem it be acceptable in our case.Many other SQLAlchemy drivers accept username/password credentials in their URLs so this does not feel any worse to me.
Describe alternatives you've considered
I have prepared a PR that I will submit.
The text was updated successfully, but these errors were encountered: