[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suppresion of password prompt
From: |
Simon Josefsson |
Subject: |
Re: Suppresion of password prompt |
Date: |
Thu, 24 Apr 2008 11:55:59 +0200 |
User-agent: |
Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) |
Graham Shaw <address@hidden> writes:
>> I see now that if the server requires pre-authentication (using a
>> password) I see now that the code will not use the provided password,
>> but instead will prompt for a new password. I have fixed this, see:
>
>> http://git.savannah.gnu.org/gitweb/?p=shishi.git;a=commitdiff;h=bdf277a51182c49b13b61ac6f57b8111dcbf94a5
>
> Thanks - that appears to work perfectly.
Ok.
>> Regarding 2), use shishi_tkts_find() instead which will only search
>> among your existing tickets. The shishi_tkts_get* APIs will try to get
>> a ticket if it doesn't exist -- it calls shishi_tkts_find() first.
>
> That isn't quite the functionality I'm looking for:
> - if the client doesn't already have a service ticket then I do want it to
> request one from the KDC using the TGT, however
> - if the client doesn't have a TGT then I don't want it to prompt for a
> password.
>
> (The former is OK because it's an entirely non-interactive process,
> whereas the latter takes input from the user so is something I need to
> avoid.)
I can think of two easy solutions:
1) Add a new Shishi_tkts_hintflags flag such as
SHISHI_TKTSHINTFLAGS_NON_INTERACTIVE which inhibits all password
queries. We probably need a new error code to signal that the command
failed for this reason.
2) Add a callback interface for dealing with password queries. This
allows you to get a callback when a password is needed. The callback
could fail (which presumably it would in a non-interactive situation).
We probably need to add the same error code here as well.
Can you think of something else that would solve your problem better?
Which do you prefer? I could implement both, they both seem useful.
Thanks,
/Simon