Shouldn't be too much work. The gem will do the heavy lifting and seems to have good docs. We will probably need appsec to do a gem review. And the majority of time spent may be us figuring out how to test the functionality. 2 to 3 seems reasonable.
Should we make a separate task for that? Would that be something you can do before we execute on this, or would it be after?
@hsutor I can perform AppSec review of the gem when the MR to integrate this feature is ready. Depending on what milestone this gets assigned, I can do a review of the gem right before the work on this gets picked up as well. The AppSec review is not a blocker to pick up work on this feature though.
I have a question though. Have we finalized doorkeeper-device_authorization_grant as the gem we would like to use to address this feature? Doing a quick Google search, this gem seems to be the only one that offers this feature so perhaps we don't have any other gems but we may want to confirm that.
I have a question though. Have we finalized doorkeeper-device_authorization_grant as the gem we would like to use to address this feature? Doing a quick Google search, this gem seems to be the only one that offers this feature so perhaps we don't have any other gems but we may want to confirm that.
I'm not sure, TBH. This is something we would need engineering expertise to look into. @adil.farrukh Should I create a spike for this and we can see where it lands?
@hsutor That gem is the only one I found from a quick search, so we can start by attempting to implement this feature via that. If we find issues during development, we can create a spike to find other ways of supporting device authorization grant time.
Was originally a 6, but priority increased on 2024/04/11
Why interested: The customer's entire firmware team is impacted by this (about 500 users). Some developers are using Linux machines without a browser, and the current workaround is to use a type of browser that is not within best practice.
Impact: The customer would need a workaround for devices to OAuth. This is directly related to self-imposed SSO. This is a long-standing improvement they’re trying to make. If it is not resolved, users will have no choice but to use SSH tokens.
PM to mention: @hsutor for visibility and prioritization
Some developers are using Linux machines without a browser
Once this feature is implemented, it sounds like git-credential-oauth would work well for these users. You can already use it to authenticate to GitHub without a local browser.
If it is not resolved, users will have no choice but to use SSH
@hickford I can't speak for them (I'm not OP), but I can tell you from our own personal usage the reason I've been following this request is because we'd like to use TOTP 2FA or SMS 2FA in the terminal(while SSHing), which we understand this feature request is an important first step. (And apparently Github already allows?)
I'll explain why:
We sometimes SSH into a server and perform GIT PULL by hand. Because some of our remote servers only have one SSH user(That is, multiple people use the same SSH user), we can't cache or save the password on those remote servers, as anyone SSHed as that user would have access to the saved credentials.
So using a personal access token means having to type the whole thing by hand every time we wanted to GIT PUSH/PULL.... which means either 1: Disabling 2FA completely, or else 2: People are saving the Personal access token in a .txt file on the desktop. Not great.
@hickford - personal access token's are acceptable, but there doesn't seem to be a clean Gitlab defined way to pull token's once a day via the command line.
@hickford Another comment - We have run into issues with pushing/pulling large monorepos from our GEO instance. The suggested work around is to use HTTPS. We are looking to have this solution for those who are struggling with SSH "proxy"s causing timeouts.
@hsutor Is there any estimated timeline for this issue to be prioritized? The priority of this has increased recently for the customer that I tagged on my earlier comment as it would help them implement a viable workaround to some long-running Geo issues that they have been facing.
@dasha This isn't on our roadmap for this year, but because it is only a weight of 3, we may be able to fit in. I'll tentatively put it into a future milestone, but no promises until Deliverable label is applied.
In your organization, what do you consider to be the highest priority for this feature proposal? According to a scale of 1-10, 1 is the lowest priority and 10 is the highest.