https://medplum.com logo
Join Discord
Powered by
Signup functionality for RegisterForm isn't proper...
# support
m
Our signup/RegisterForm process results in incorrect & undesired outcome where the https://api.medplum.com/oauth2/token request URL endpoint is hit, and the POST request results in a 404, and on the actual site, only a empty JSON object response is shown, without any response, so the only way to see into the issue is through the network tab in the chrome dev tools, where we also come to find out that the server request is hanging/stalling. Would love to have help on this issue in order to keep the signup/register functionality smooth.
r
Tell me more - is your app running on localhost and you have incorporated the signin form? What configuration/params are you using? https://storybook.medplum.com/?path=/story/medplum-signinform--with-links
m
Hi Reshma, so the app is running on localhost yes, and we incorporated the RegisterForm component (https://storybook.medplum.com/?path=/story/medplum-registerform--with-google). The params are type: projectId (env variable) recaptchaSiteKey (env variable) googleClientId (env variable) onSuccess function
The setup seems to be correct by the looks of it.
r
m
Awesome! Thanks, i'll be on the lookout!
Hi Reshma, i wanted to followup on the other issue i mentioned when first creating this post, which is having the undesired outcome where the https://api.medplum.com/oauth2/token request URL endpoint is hit, and the POST request results in a 404, and on the actual site, only a empty JSON object response is shown, without any response, so the only way to see into the issue is through the network tab in the chrome dev tools, where we also come to find out that the server request is hanging/stalling. I will provide screenshots down below, and would love to learn how to figure this out: 1st picture: Right after clicking create account, this is shown in the UI 2nd picture: the header showing which endpoint is being hit, shown in the chrome dev tools network tab 3rd picture: the timing of the request showing that the server is stalling and the request isnt finished
r
Got it, can you DM me your account details (Project ID, which user was attempting to authenticate)? One issue potentially here is that the Patient or Practitioner associated with this User was deleted.
m
That is the main issue, this is for creating a new user, for signing up to create an account. Everything with logging in as an existing user works correctly to my knowledge.
r
Sorry for the back and forth here Mikee. I have attempted to repro on production and localhost and am unable to - here's the video of what I believe you are doing let me know if I'm off base https://share.descript.com/view/WvCV7QmdWBt It seems like the delta is between your account configuration somehow. A default patient access policy must be in place. Also should make sure that your Client Application has the admin permissions.
Is this consistent? "and the POST request results in a 404"
m
I attached videos down below of exactly whats going on, I created a new user with a new email, proper password, and the user doesn't exist in the db. After clicking the create account button, this is what is seen on the screen.
medplum-bug-pt1
r
Hi Mikee, I just checked that your users are being created, but for some reason it's not logging in correctly from that register page. Could you try a few things? - Are you able to sign in as newuser3@gmail.com from your signin page (as opposed to register page)? - If that doesn't work, can you sign in as that user at https://app.medplum.com/signin
Hi @mikee6290 , I have an update for you. Seems like we might have had a bug in our registration flow, when you specify a clientId. I've filed the issue here and we should have a fix shortly: https://github.com/medplum/medplum/issues/2431
m
Hey thanks so much for diving in to all this. We're currently working through the info you mentioned above to help us with the register bug.
I wanted to throw this question out there and see if this may be something you guys may have looked into, but does this api function, here which is being called at the endpoint oauthRouter.post('/token', tokenHandler); on the routes file for outh?
Specifically the if conditional on line 44.
r
yes, we looked into this file. The issue is probably on 169. Since you're passing in a clientid, it needs to match the 
Login
resource that was created before. But the bug I filed was because it was not being set correctly in the 
Login
One way to test this is to remove the 
clientId
the prop from your RegisterForm
Hi @mikee6290 , we just pushed a fix. Do you mind trying it again https://github.com/medplum/medplum/pull/2434/files
m
So i retried it, I updated to the latest version of medplum as well. Like before a new user is being created, however now the difference is that the request goes through right away and isnt hanging, however we are getting this JSON object on the UI.
medplum-bug2
r
@mikee6290 - we're very sorry for the protracted debugging. We've identified another issue with our UI component that we're fixing asap: https://github.com/medplum/medplum/pull/2452 However, it will take a full release cycle (2.0.26) for you to receive the change
In the meantime, you can avoid this issue by not passing in a 
clientId
into the constructor of your 
MedplumClient
in main.tsx. By not passing in the clientId, you'll avoid the buggy code path
Again, we're sorry for the rough edges here, and we'll get this fixed and documented asap
m
I understand, i'll keep an eye out for your messages just in case and for the new release. Not passing the clientId in the constructor of the MedplumClient did make it work for now. If theres anything I can do to help, please let me know 🙂
r
Thank you so much for your patient @mikee6290 . I'll make sure to follow up when there's a new release
Hi @mikee6290 , wanted to follow up that we've published a new release. If you upgrade to 2.0.26, you should be able to add the 
clientId
back in to the constructor. Sorry again for the inconvenience
m
Hey @rahul1 , I hate to keep bothering you and not coming back with the progress we want 😭 . So i updated to the new version of medplum, and i have the client ID in MedplumClient constructor, everything seems to be configured properly, but now i'm getting the error in the image attached. I also attatched an image of the code where Im setting up the Medplum Client. Let me know if theres more info i can provide.
r
No worries! We're sorry about the protracted debugging loop. Would you mind posting a full video of your browser like you did before. Seeing all the different tabs in the developer tools was quite useful
m
Sure! Ill attatch it below.
medplumsignin
r
ok qq - are you passing in the clientId into your RegisterForm as a prop? It's a new prop in the latest release
m
Oh, no we're not, we're passing in the projectId, recaptchaSiteKey, and googleClientId.
r
So sorry, I should have made that clearer in my instructions
m
I will give that a go right now!
r
v2.0.26 added a new prop to pass into the ReactComponent, which then tracks the clientid all teh way through the register flow
m
Works now! Looks like that was the missing part. Was that something we should have had in the previous videos i showed you? Or was this added in this new release?
r
Sorry again for the painful debugging
Upon further reflection, if you MedplumClient has the 
clientId
set, we probably should just read that if you don't pass it in as a prop. That might make it a bit more ergonomic. I can make that update
m
Im not sure I understand, where would it be read from if its not passed in as a prop?
r
Oh you're doing the right thing by passing it in!
I was just thinking that our implementation creates a sub-optimal experience foryou, since you have to pass in the clientId twice: once in the 
MedplumClient
constructor, and once in the 
RegisterForm
as a prop. In our next release (2.0.27), we'll make it so you don't need that 2nd step (PR here: https://github.com/medplum/medplum/pull/2472)
m
Oh I see, its not an inconvenience at all, but I'll be on the lookout for the next release!
161 Views
PreviousNext
Powered by