Expose Meteor user context to Express endpoints

[ceigey]

Oooh, very interesting! I guess the benefit of using the same context is now you can use the same underlying function for a WebApp endpoint or a Meteor methods endpoint…

I just had a quick skim through the code and I can see you’re handling the expiring tokens which was the one thing I wanted to check

As later additions?, I think it’d be nice to also have:

• Login (with login token generation, expiries etc all consistent with DDP login)
• Logout
• Arbitrary tokens e.g. a long-lived API Token.

The first two I think were covered by this user’s custom middleware:

Meteor-rest equivalent for meteor v3

In meteor v2 Ive previously used meteor-rest to create a json api for my meteor app. meteor-rest is no longer supported, and in meteor v3 I understand that I can use Express and its ecosystem. Does anyone have any good pointers (beyond the migration guide) for doing this and: creating endpoints to login (returning bearer token) and logout creating middleware to use that bearer token in my custom rest routes or perhaps some hints to an alternative strategy? bw Matt

I think after all that, Meteor’s half way to internalising the same kind of functionality simple-rest etc had into the core (the next step would be figuring out how to safety expose HTTP endpoints for pub/sub, methods etc ). Still perhaps best left to a 3rd party package (or alternatively, the separate efforts to improve Meteor method declarations), but at least the accounts plumbing is a lot simpler!