- If they're in deferred-registration state, give them their
registration link and exit.
- Before running the login prompt, mention that it's a Meteor developer
account which you can sign up for on www.meteor.com.
_.once has the problem that if you call the once'd function while it is
still in progress (re-entrantly or in another Fiber), it returns
undefined immediately. That's bad for uniload! uniload already has a
cache, so just use that. (In the future, perhaps detect an attempt to
uniload something that's currently in the process of being uniloaded in
another fiber and block until the other fiber is ready.)
Using instanceof with things you've uniloaded is a little sketchy: maybe
two different uniload calls will end up with two different copies of
Package.meteor.Meteor.Error, and it seems kind of hairy to ensure you're
not mixing and matching copies. However, Meteor.Errors are all tagged
with a string errorType, which fills me with much less fear,
uncertainty, and doubt than instanceof.
Port a simplified version of Meteor.EnvironmentVariable and
Meteor.bindEnvironment to fiber-helpers.js to deal with this.
Identify uses of fiberHelpers.inFiber and switch them to either
fiberHelpers.bindEnvironment (if the callback they are wrapping is
semantically "part of" the context that creates the callback) or
fiberHelpers.inBareFiber (otherwise).
Without this, concurrency was causing the wrong buildmessage message
sets and jobs to be active when builds yielded.
springboarding happens infinitely because of build ids
have to manually bootstrap a tropohouse
fixed some other things:
- store package server token in correct domain
- copy files (eg packages pre-publish) with +x flags
- catalog.getReleaseTrack works
- don't pass release to uniload (Meteor.release will always
end up 'UNILOAD')
- fix building meteor-tool again
- stop supporting apps without .meteor/release
- merging unipackages with tools works
springboarding to warehouse releases totally not supported
When we deploy:
* If we are logged in with a username, then we go straight to doing the
actual deploy.
* If we are logged in without a username, we check if we have a username
yet. If we have an invalid credential at this point, we do NOT want
`pollForRegistrationComplete` to wipe our session file, because we
already passed the point at which we handle the case of the user being
logged out. Instead, we just want to continue with the deploy and let
the deploy server handle the expired credential. (This case, where a
user's credential has been expired before they set a username,
shouldn't happen too often in real life.)
* If we deploy with an invalid credential, we get an "Expired
credential" message.
This is consistent with old password prompts (see #1600), and also makes
it so that everyone who calls `doInteractivePasswordLogin` is using the
same stream as `doInteractivePasswordLogin`.
From tool-refactoring to sso.
Makes the tool-refactoring/sso diff a little smaller (including removing
some files from it entirely) and easier to review. Only took about five
minutes to prepare, I swear this isn't a total waste of time :)
Require token revoke endpoints to return JSON with a `tokenRevoked` key,
to avoid being fooled by endpoints that don't understand token
revocation but just happened to return 200 status codes.
