Implementing nsITokenPasswordDialogs is too burdensome

RESOLVED WORKSFORME

Status

()

Core
Security: PSM
RESOLVED WORKSFORME
13 years ago
2 years ago

People

(Reporter: Simon Fraser, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kerh-ehz])

(Reporter)

Description

13 years ago
nsITokenPasswordDialogs has two methods, and must be implemented by embedders
which want to provide basic security UI:

  void setPassword(in nsIInterfaceRequestor ctx, in wstring tokenName,
                   out boolean canceled);

  void getPassword(in nsIInterfaceRequestor ctx, 
                   in wstring tokenName,
                   out wstring password,
                   out boolean canceled);

Unlike the other security UI interfaces, correctly implementing these is hard,
and requires a fair amount of logic that should really live in the NSS code.

The hard one is setPassword(). This has to figure out if the slot with the given
token name is uninitialized, and show different UI in that case, and then call
APIs on the token to init or change the password.

Issues with this:
* The burden of looking up slots and tokens is on the embedder. Why can't this
  api pass me in a slot and/or token?
* The embedder has to figure out if this is a new PW, or changing an existing
  PW. Why can't the caller do this?
* It's not clear what to do for slot statuses other than SLOT_UNINITIALIZED
  and SLOT_READY.

Updated

13 years ago
Whiteboard: [kerh-ehz]
QA Contact: psm

Comment 1

6 years ago
reassign bug owner.
mass-update-kaie-20120918
Assignee: kaie → nobody
Looks like getPassword was removed at some point. If this API is still troublesome, please reopen this bug.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.