… release specifier encodes the platform (el6) : issue #2791
…nd the user is not authenticated.
…IE forced into compatibility mode
…rage data To run 'PERSONA_WITH_COVER=1 npm test'. Changes to lockdown.json are: firstname.lastname@example.org -> email@example.com firstname.lastname@example.org -> email@example.com -> firstname.lastname@example.org -> email@example.com -> firstname.lastname@example.org
This should allow multiple primaries to delegate control to the same server, by letting the server know which domain we're interested in. This is similar to how the HTTP "Host" header enables named-based virtual hosting. Both the Verifier and the user agent (specifically the /wsapi/address_info handler) will add this argument. Servers which host only one key can ignore it. Also allow arbitrary queryargs in bin/proxy, otherwise it denies requests with queryargs. This should help Bigtent do dynamic .well-known lookups.
We now pass two arguments into each getWellKnown() and parseWellKnownBody() call. The "fromDomain" argument changes on each delegated lookup (it indicate which server we're fetching .well-known/browserid from *right now*), while "principalDomain" remains constant (and indicates which domain we really care about, regardless of who we're currently asking about them). This shouldn't change any behavior. It just paves the way for a later change to add principalDomain as a query arg.
This renames the various "domain" parameters to avoid collision and emphasize what exactly is meant. "fromDomain" is the domain that we're currently fetching a .well-known/browserid file from; when we're recursively following delegations, fromDomain is different on each loop. "principalDomain" is constant: it is taken from the principal's email address and remains the same for each loop. This shouldn't change any behavior. This paves the way to split fromDomain and principalDomain, and to pass principalDomain into each lookup. getWellKnown() passes its fromDomain parameter off to its callback.. I'm not sure why (might be to avoid late-binding confusion in the delgation case). That argument was renamed to newDomain in the closures passed into getWellKnown(), since previously it sometimes overlapped with the "domain" argument being passed in.
Fix siteName in dialog regression I am comfortable with this fix as a fix to the problem as described. The larger problem of elements with duplicate IDs is not yet fully handled. The IDs of the tooltips relating to the email address and password are duplicated in add_email.ejs and set_password.ejs. I tested across several browsers (Firefox OSX, Chrome OSX, Fennec, Android Native browser, IE8 on WinXP) to see if this would cause a problem, so far all the tooltips show when expected. This fix gets an r+, opening a new bug for the other duplicate IDs. Nice work @seanmonstar.