Closed nichtich closed 1 day ago
As described at #80 this strategy is going to be used with CBS/PSI in two use cases:
"id":"DE-7", "name":" "SUB Göttingen"
=> "uri":"http://uri.gbv.de/organization/isil/DE-7"
Just committed the first implementation. We still need documentation, in particular:
Also I have more questions regarding the implementation:
USERNAME
and PASSWORD
are used.)name
or displayName
are used for the display name. If neither is given, "username@provider" is used as a fallback. So we need to decide whether to use name
or displayName
(or we can allow both options for more flexibility). Also we don't normally need username
if it's not different from id
.id
is given, it is assumed that validation of credentials failed.What do you mean by "and as arguments for array elements being $USERNAME or $PASSWORD, respectively"?
Well, passing the credentials per environment should be enough, so ignore this.
I don't get the difference between name
and displayName
and why we have username
at all.
Absence or empty field id
is an error as implemented.
Well, passing the credentials per environment should be enough, so ignore this.
👍
difference between
name
anddisplayName
There is no difference. Some OAuth providers use one, some use the other. We can just use name
. (I can imagine that some providers offer to set both a full name (name
) and a separate display name (displayName
).)
and why we have
username
at all.
Because for some providers, the id
is a random number, but we still need the username
to build the URI (I think this is the case with GitHub, for example).
Absence or empty field
id
is an error as implemented.
For now, I'm just going to assume that any output where id
is empty or not set is a failed authentication, and not differentiate between WHY something failed. I don't think we currently have a mechanism to report those reasons to the user anyway, it'll just show that authentication has failed.
Strategy to ask for username and password to be passed to a local executable script/binary in the server file system. Requires option
command
to call the script, e.g.["/some/login/script", "-u", "$USERNAME", "-p", "$PASSWORD"]
. or["/path/to/script"]
. The script gets username and passwort in environment variablesUSERNAME
andPASSWORD
and as arguments for array elements being$USERNAME
or$PASSWORD
, respectively. The script must return a JSON object and not return an error exit code. Field names of the JSON strict are not defined yet (likelyid
(required account id),name
(optional account name) and/orusername
(optional display name)). A useruri
can be generated fromtemplate
of provider configuration like for other strategies.