How do you provide credentials (when fetching)?

[philipahlberg]

I'm trying to fetch from a private repository. My code looks something like this (with error handling replaced by .unwrap()):

let repo = gix::discover(".").unwrap();
let outcome = repo.find_default_remote(Direction::Fetch)
    .unwrap()
    .unwrap()
    .connect(Direction::Fetch, gix::progress::Discard)
    .unwrap()
    .prepare_fetch(Default::default())
    .unwrap()
    .with_dry_run(true)
    .receive(&gix::interrupt::IS_INTERRUPTED)
    .unwrap()

As far as I can tell, in order to provide credentials to the fetch operation, I would have to call .with_credentials on the Connection:

    // ...
    .connect(Direction::Fetch, gix::progress::Discard)
    .unwrap()
    .with_credentials(|action| match action {
        Action::Get(ctx) => Ok(Some(Outcome {
            username: Some("username"),
            password: Some("password"),
            quit: false,
            next: todo!(),
        })),
        Action::Store(_) => todo!(),
        Action::Erase(_) => todo!(),
    })
    // ...

This is as far as I've gotten however. I'm not sure why I'm expected to handle the Store and Erase actions at this point (am I using the wrong hook?), but more importantly, I don't understand what next in Outcome is supposed to be here, and I can't find a way to actually construct a NextAction. What am I missing?

On a possibly related note, the default configuration does not handle authentication in the same way as my git installation does. I can git fetch without being prompted for my username and password, but when I use the gix library, it prompts every time. Is that expected?

[Byron]

The reason this seems a bit cumbersome is that it's essentially the credential-helper protocol turned into a Rust API. The handler can obtain credentials, and later store or erase them depending on whether they worked or not. Such calls you would be ignoring then.

ctx can be turned into next via next: ctx.into() which should be fine as the username and password seem to be hardcoded anyway. Suffice to say that I consider this an example and in real life this wouldn't be hardedcoded like that.

On a possibly related note, the default configuration does not handle authentication in the same way as my git installation does. I can git fetch without being prompted for my username and password, but when I use the gix library, it prompts every time. Is that expected?

gix shouldn't prompt every time but instead use the git credential helper. To learn why that is more information would be required, like the platform gix runs on, its version and the protocol used to address the remote repository.
Thus the code above should work without hand- or hard-coding any credentials (once another issue is fixed). But if gix can't do it it's a different issue entirely. If you can provide enough information that helps to reproduce the problem or understand it, please feel free to create an issue. Thank you.

[philipahlberg]

ctx can be turned into next via next: ctx.into() which should be fine as the username and password seem to be hardcoded anyway. Suffice to say that I consider this an example and in real life this wouldn't be hardedcoded like that.

Thanks, seems like this is what I had missed.
It is indeed just for the example. Would next: ctx.into() still be fine in cases where the username and password are not hardcoded? I'm not sure what the implications are.

gix shouldn't prompt every time but instead use the git credential helper. To learn why that is more information would be required, like the platform gix runs on, its version and the protocol used to address the remote repository.
Thus the code above should work without hand- or hard-coding any credentials (once another issue is fixed). But if gix can't do it it's a different issue entirely. If you can provide enough information that helps to reproduce the problem or understand it, please feel free to create an issue. Thank you.

Hm, I see. My current config (git config credential.helper) is osxkeychain, so maybe that is what is causing issues. It might be the gh utility that sets it up like that when authenticating via gh auth login. Sounds like it's not working as intended though, so I'll create an issue with the information you mention.

Thanks for the assistance!

[Byron]

It is indeed just for the example. Would next: ctx.into() still be fine in cases where the username and password are not hardcoded? I'm not sure what the implications are.

The credentials in ctx should match the ones of the outcome. The ctx is what's then passed to store and erase - here it's not an issue as the credentials are hardcoded.

[..] so I'll create an issue with the information you mention.

Thanks, I use MacOS too so that should help understanding what's going on. gix should find the credential helper and invoke it just like git does, so it's strange to see this fail. I will move over to the issue now.

[philipahlberg]

Sorry to bother you again, but I'm bumping into a panic when trying to use .with_credentials:

    // ....
    .with_credentials(|action| match action {
        Action::Get(ctx) => Ok(credentials.map(|c| protocol::Outcome {
            identity: Account {
                username: c.username.clone(),
                password: c.password.clone(),
            },
            next: ctx.into(),
        })),
        Action::Store(s) => Ok(None),
        Action::Erase(s) => Ok(None),
    })

This crashes with:

thread 'main' panicked at 'FILL provides an identity or errors', $CARGO_HOME/registry/src/gb.xjqchip.workers.dev-1ecc6299db9ec823/gix-protocol-0.30.0/src/handshake/function.rs:48:21

Assuming I can safely ignore Action::Store and Action::Erase, I must then be doing something wrong with ctx.into(). What am I doing wrong?

[philipahlberg]

Ok, so that's just what happens when you return Ok(None). It would be nice if that could be an error instead of a hard panic though, but I suppose I can work around it for now. Once again, thanks for your assistance. :)

[Byron]

I see, this is a valid point actually - the implementation right now expects to see one particular implementation (the one that drives credential helper programs) and correctly assumes that empty credentials should never happen. However, that's clearly not what the type-system thinks or what actually happens, so it's an issue to fix. It's done in: d4c82e7