You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I kind of looked into this a bit for fun, as a next step now that the CLI is a bit easier to use. I think it would be possible to do conveniently only for GitLab.com, if we
register an OAuth app on GitLab.com (e.g. a group-level oauth app from python-gitlab/ with PKCE)
commit the client ID in the repo (at least that's what gh does, even the secret actually, see below), and then
follow the PKCE flow. A nice description is actually available for this in the pkce-flow package.
But for self-managed users would probably need to create their own OAuth apps and paste in the ID and instance URL, so the convenience over just creating a PAT in the web UI is kind of lost. It would actually be easier then to just steal the browser cookies and create a PAT like that, which seems hacky to me. Or no? 😁
If I'm not mistaken, it seems gh can get away with this because their CLI app is completely baked into the GitHub.com as well as GitHub EE servers themselves (just by reading things like cli/cli#4523, but I can't tell as the rest is closed source).
As most people are using gitlab.com, we could think about adding this.
How did you come up with this? Probably this would be valid in the OpenSource world, but EE very likely uses self-installed variant for different reasons I have the feeling (and also speaking for myself)
@mstenz yes I'd say that assumption is for open source.
For self-hosted EE (or Free) instances, we can't really do this flow without users also providing the instance URL and someone creating an OAuth application on that instance, then providing its client ID. At that point it makes more sense to just create a token IMO.
maybe you can add something like question(s) where the user can put in these fields very easily and probably also save them in a connection file so it is not required to be entered all the time.
This issue was marked stale because it has been open 60 days with
no activity. Please remove the stale label or comment on this
issue. Otherwise, it will be closed in 15 days.
As an open-source project, we rely on community contributions to
address many of the reported issues. Without a proposed fix or
active work towards a solution it is our policy to close inactive
issues. This is documented in CONTRIBUTING.rst
How to keep this issue open:
If you are still experiencing this issue and are willing to
investigate a fix, please comment and let us know.
If you (or someone else) can propose a pull request with a
solution, that would be fantastic.
Any significant update or active discussion indicating progress
will also prevent closure.
We value your input. If you can help provide a fix, we'd be happy
to keep this issue open and support your efforts.
This issue was closed because it has been marked stale for 15 days
with no activity.
This open-source project relies on community contributions, and
while we value all feedback, we have a limited capacity to address
every issue without a clear path forward.
Currently, this issue hasn't received a proposed fix, and there
hasn't been recent active discussion indicating someone is planning
to work on it. To maintain a manageable backlog and focus our
efforts, we will be closing this issue for now.
This doesn't mean the issue isn't valid or important. If you or
anyone else in the community is willing to investigate and propose
a solution (e.g., by submitting a pull request), please do.
We believe that those who feel a bug is important enough to fix
should ideally be part of the solution. Your contributions are
highly welcome.
Thank you for your understanding and potential future
contributions.
Activity
nejch commentedon Jan 9, 2022
I kind of looked into this a bit for fun, as a next step now that the CLI is a bit easier to use. I think it would be possible to do conveniently only for GitLab.com, if we
python-gitlab/with PKCE)ghdoes, even the secret actually, see below), and thenBut for self-managed users would probably need to create their own OAuth apps and paste in the ID and instance URL, so the convenience over just creating a PAT in the web UI is kind of lost. It would actually be easier then to just steal the browser cookies and create a PAT like that, which seems hacky to me. Or no? 😁
If I'm not mistaken, it seems
ghcan get away with this because their CLI app is completely baked into the GitHub.com as well as GitHub EE servers themselves (just by reading things like cli/cli#4523, but I can't tell as the rest is closed source).See:
https://github.com/cli/cli/blob/a9b2c0dc82158a1d31fd9c3c2d94e5f2511be98a/internal/authflow/flow.go#L17-L24
and
https://github.com/cli/cli/blob/eaa64df80193f4f632d574f25729460d8b657819/internal/authflow/flow.go#L76-L78
But maybe I'm just a bit clueless here with OAuth. Open to ideas @max-wittig @JohnVillalovos 😅
Edit: FWIW,
glabalso just points people to the preferences page to create and paste a token. Maybe that's a reasonable start. https://github.com/profclems/glab/blob/925d768472efc2a60c2f631b11f132bb2cf3806b/commands/auth/login/login.go#L335-L338max-wittig commentedon Jan 10, 2022
Thanks for your investigation @nejch. As most people are using gitlab.com, we could think about adding this.
Otherwise it's really mostly a one-time thing for most users, maybe a message is really enough for now.
mstenz commentedon May 8, 2023
How did you come up with this? Probably this would be valid in the OpenSource world, but EE very likely uses self-installed variant for different reasons I have the feeling (and also speaking for myself)
nejch commentedon May 8, 2023
@mstenz yes I'd say that assumption is for open source.
For self-hosted EE (or Free) instances, we can't really do this flow without users also providing the instance URL and someone creating an OAuth application on that instance, then providing its client ID. At that point it makes more sense to just create a token IMO.
mstenz commentedon May 8, 2023
maybe you can add something like question(s) where the user can put in these fields very easily and probably also save them in a connection file so it is not required to be entered all the time.
nejch commentedon Sep 26, 2023
There is now some motivation on the GitLab side to make this more feasible across self-managed instances as well:
https://gitlab.com/gitlab-org/gitlab/-/issues/413809
We could potentially hook into that if it gets implemented. Then the gitlab.com vs self-managed discussion is no longer needed :)
github-actions commentedon Jul 9, 2025
This issue was marked stale because it has been open 60 days with
no activity. Please remove the stale label or comment on this
issue. Otherwise, it will be closed in 15 days.
As an open-source project, we rely on community contributions to
address many of the reported issues. Without a proposed fix or
active work towards a solution it is our policy to close inactive
issues. This is documented in CONTRIBUTING.rst
How to keep this issue open:
investigate a fix, please comment and let us know.
solution, that would be fantastic.
will also prevent closure.
We value your input. If you can help provide a fix, we'd be happy
to keep this issue open and support your efforts.
This is documented in CONTRIBUTING.rst
https://github.com/python-gitlab/python-gitlab/blob/main/CONTRIBUTING.rst
github-actions commentedon Jul 24, 2025
This issue was closed because it has been marked stale for 15 days
with no activity.
This open-source project relies on community contributions, and
while we value all feedback, we have a limited capacity to address
every issue without a clear path forward.
Currently, this issue hasn't received a proposed fix, and there
hasn't been recent active discussion indicating someone is planning
to work on it. To maintain a manageable backlog and focus our
efforts, we will be closing this issue for now.
This doesn't mean the issue isn't valid or important. If you or
anyone else in the community is willing to investigate and propose
a solution (e.g., by submitting a pull request), please do.
We believe that those who feel a bug is important enough to fix
should ideally be part of the solution. Your contributions are
highly welcome.
Thank you for your understanding and potential future
contributions.
This is documented in CONTRIBUTING.rst
https://github.com/python-gitlab/python-gitlab/blob/main/CONTRIBUTING.rst