Re: SecretAgent.GetSecrets() return value

[Dan Williams <dcbw redhat com>]

On Tue, 2011-09-06 at 23:03 +0100, Daniel Drake wrote:
> On Tue, Sep 6, 2011 at 10:54 PM, Dan Williams <dcbw redhat com> wrote:
> > Not sure I follow this...  you shouldn't need a secret agent if all that
> > the UI is doing is Update() and AddConnection().  A secret agent is only
> > required if there are any agent-provided secrets (ie, some secret has
> > the flag AGENT_OWNED).  If you let NM handle all secrets then no secret
> > agent should be required; initial secrets get to NM via the
> > Connection.Update() call, which shouldn't require a secret agent (as
> > long as all secrets are not AGENT_OWNED).
> 
> The way I've implemented it at the moment is (I think) the same as
> nm-applet. I implement the SecretAgent interface, but I don't set any
> special flags, so the secrets do get stored by NM.
> 
> However, the first time a connection is established, NetworkManager
> needs to communicate the need for secrets, Sugar then needs to request
> the info from the user and communicate it to NM. I implemented
> SecretAgent for that purpose, and it is working.
> 
> I think you might be suggesting that before activating a connection,
> Sugar somehow queries NM to see if secrets are present, and if they
> aren't, it pops up a dialog requesting them, then it modifies the
> connection to add the secrets, then it activates it?

Not quite; for most connection types you can figure out beforehand if
secrets are required and ask for them, and send them to NM in the
AddAndActivate() or the AddConnection() calls.  The applet used to do
that by doing a combination of special logic and
nm_connection_need_secrets() calls on the connection the applet had
constructed based on the AP scan result or whatever.  That's one
possibility.  A secret agent is probably more logic than that, but more
flexible.

Like you say if a secret is wrong or needs to be changed, there's no
facility to ask for that secret.  We can (and should) make sure NM would
fail the connection with a NM_DEVICE_REASON_NO_SECRETS or something like
that if NM can find out the secrets are wrong, which could trigger the
applet to toss up the "your connection failed, please re-enter your PSK"
dialog or whatever.

Or, if you use a secret agent, NM will ask for the secrets when it
thinks it needs them.  Currently that's too often, but we hope to make
NM smarter about this in the near future.

> It seems roundabout but it might work, but I wonder what happens when
> the secrets are wrong or the password has changed, and the user needs
> to be prompted? Seems like impementing SecretAgent (for the purpose of
> prompting the user when the user needs to be prompted, not for the
> purpose of actually storing secrets) would smooth out those corner
> cases, and it looks like nm-applet works this way.

Yes, it would smooth out those cases, and since you most likely already
have the code to ask for secrets in the connection editor-type case, you
can call that for the secret agent bits.  You also don't need to
implement the save/delete secrets calls of the Agent API since you
shouldn't need to be storing secrets given that you're not marking them
AGENT_OWNED.  So you're just implementing GetSecrets() which shouldn't
be a ton of work.

Return value should be a hash table of hash tables (basically an
NMConnection of only the secrets), so for example if you're returning a
WPA-PSK connection's secrets, it would be simply:

wsec = { 'psk': 'some-really-secure-psk' }
hash = { '802-11-wireless-security': wsec }
return hash

Dan


Dan