Transferring from the dev forum
# support
m
I would like to build a node program that uses the medplum libraries as a pure backend job. I think we will need to do these sorts of operations as a part of various batch jobs that run outside of medplum (so, if I am understanding things, not bots) The code I am running is just export async function App(): Promise { const medplum = new MedplumClient(); const loginAuth = await medplum.startLogin({ email: "mgolden@mitchgolden.com", password: "LateWrittenThoseMade0", }); console.log(loginAuth); } The issue I am having is that I see the core uses a reference to the Storage class. This is a browser-only construct. The error I get is ReferenceError: sessionStorage is not defined at Mt.startPkce (file:///home/mgolden/clients/humanaut/medplum-initial-test.old/node_modules/@medplum/core/dist/esm/index.mjs:43:11961) at Mt.ensureCodeChallenge (file:///home/mgolden/clients/humanaut/medplum-initial-test.old/node_modules/@medplum/core/dist/esm/index.mjs:3:47225) at Mt.startLogin (file:///home/mgolden/clients/humanaut/medplum-initial-test.old/node_modules/@medplum/core/dist/esm/index.mjs:3:46911) at App (file:///home/mgolden/clients/humanaut/medplum-initial-test.old/dist/src/app.js:4:37) What I am trying to do is just use medplumClient.startLogin({ email: "mgolden@mitchgolden.com", password: "...", }); and see the response.
@rahul1 I don't see any static methods on medplumClient. It would seem to me that as I understand the way startLogin is operating, it should essentially be a constructor.
r
maybe basic auth is useful for this use case? https://www.medplum.com/docs/auth/methods#server-side
CLI is also useful for batch jobs https://www.medplum.com/docs/cli
m
Looking at this now. So is the idea that startLogin is always for a browser? The documentation is not clear on that if that is the case.
r
@mitch_83302 thanks for flagging, and I agree that the documentation should reflect this more properly
The suggestion of basic auth is because, for communication from a trusted environment, it tends to be more performant. There is no handshake to create an auth token, and the bearer token does not need to be stored
If also want to layer on access restrictions based on a specific user, you can use the
on-behalf-of
header. This would allow you to have a server-to-server authentication, but still restrict all the interactions to the permissions allowed to a specific user https://www.medplum.com/docs/auth/methods/on-behalf-of
321 Views