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
If this works it'd be possible to supply the username and token as an environment variable instead of messing with ssh keys. It's also easy to revoke tokens if necessary.
@manics: I completely agree that the token-based HTTPS URL are very attractive and managing only tokens as opposed to tokens + SSH keys would be very advantageous. For instance, I use a development token for testing/pushing tags to @snoopycrimecop manually to prevent interfering with my own SSH keys.
The main downside/amount of work I see with this proposal is that the scc library was been written with the SSH URLs in mind. This would need to be updated to support token-based approach. Additionally, we would need to review all places where a token might be leaked publicly via the remote URL.
Additionally, we would need to review all places where a token might be leaked publicly via the remote URL.
My reading of the git-credentials links is that the token can be read automatically from a file store, and doesn't need to be included in the HTTPS URL.
If this works it'd be possible to supply the username and token as an environment variable instead of messing with ssh keys. It's also easy to revoke tokens if necessary.
The text was updated successfully, but these errors were encountered: