mikewest
commented
8 years ago Just to make sure I understand, I think you're suggesting something like the following, which would fold the credential lookup/mediation into the fetch API:
var options = {
password: true
};
fetch("https://example.com/endpoint", {
method: "POST",
credentials: options // as an alternative to "include"?
});I have a few thoughts:
- The separation between
navigator.credentials.get()andfetch()allows a few use cases that this model doesn't. Consider a future FIDO extension which usesget()to obtain aFIDOCredentialthat has some assertion methods hanging off of it, or the existingFederatedCredential, which isn't directly submitted to a same-site endpoint, but is instead used to trigger a call to a particular identity provider's authentication SDK. These tend to require presenting the site with aCredentialobject of some sort, which I think this model would have a hard time serving. - It's unclear how we'd want to handle the
unmediatedoption for automatic sign-in (or, for that matter, a user denying access to credentials via whatever UI a mediated request presented). How would a developer deal with failures due to credentials not being available without user mediation vs. a network error that caused Fetch to fail?
Rather than folding the lookup step into Fetch itself, what do you think about obtaining a Credential object as outlined in the document, and then passing that Credential object into fetch()?
That is, change RequestInit to:
typedef (PasswordCredential or RequestCredentials) CredentialInfo;
partial dictionary RequestInit {
CredentialInfo credentials;
}and call fetch() as
navigator.credentials.get(options).then((c)=>{
if (c)
fetch("https://example.com/", { credentials: c, method: "POST" });
});We would still throw if a body was provided, the body would still appear empty to various bits and pieces that inspected the generated Request, and the PasswordCredential could be piped through to "HTTP-network-or-cache fetch" and injected as the body there.
Would that still address your concerns?
/cc @annevk @AxelNennker
annevk
wanderview
jakearchibald
Currently a fetch Request has a .credentials value indicating whether or not cookies should be sent with the request. These cookies are added as headers at the network layer. So the cookie headers are not available to script anywhere.
The currently proposed API in this repo, however, works completely differently. Instead of setting the credentials at the network layer they are set as the body up front in the constructor. The API then adds additional mechanisms for hiding the body from script.
As an alternative I'd like to suggest that we try to unify with the current fetch credentials systems:
1) A
CredentialRequestOptonsobject can be provided to theRequest()constructor. It gets attached as some internal value. Providing both this value and a separate body would throw synchronously in the constructor. 2) The Request functions normally to script. The body can be inspected, but simply shows an empty body. This is consistent with a Request with cookie credentials where the headers are simply not exposed. 3) At the network layer theCredentialRequestOptionsfrom (1) is used to lookup any credentials which are then serialized to the body. (Not sure if we should fail the request or proceed without credentials if the lookup fails. This could be controlled by an option toRequest().)This would directly map to our current fetch credential system. Step (1) is like passing
{ credentials: 'include' }toRequest(). Step (2) is mirrors how we simply hide cookie headers today. Step (3) looks up and attaches the credentials at the same time that cookies are handled today.In addition to being more consistent with the current system, this approach would also work better with the Cache API. If we serialize the actual Credential object into Cache and then the password is changed, using that Request out of the Cache will fail. With this alternate approach, however, we would look up the new password at the network layer and everything would continue to work.
Finally, I prefer this approach because I think adding an opaque variant of Request adds unnecessary complexity. Creating an opaque Request type can break existing libraries working with Request objects. Previously they could consistently access the body without throwing, but not if a Request is marked opaque at construction time.