Stream: subscriptions
Topic: Any 4.0.0 servers that support web socket subscriptions?
Brian Reinhold (Apr 30 2019 at 22:07):
Hook subscriptions are a bear to configure because of firewalls, routers, and what have you. So if there is anyone with a 4.0.0 server supporting websockets subscriptions please let me know! Hopefully you will be at the connectathon this Saturday.
Michele Mottini (Apr 30 2019 at 22:27):
I am working on one now - I'll have something working at the cthon but very very (very) rough
Michele Mottini (Apr 30 2019 at 22:35):
Can you use ws: or you need wss: ?
Brian Reinhold (Apr 30 2019 at 23:56):
I am working on one now - I'll have something working at the cthon but very very (very) rough
I suppose I can use either! I too am working on something and it will be really rough. My main interest is to upload PHD data following the PHD IG, exercise the new Device resource, and subscribe to the data. The former I am well versed in ... the latter I am a total greenhorn!
Do you have a URL for upload (transaction bundles) and a subscription websocket address? I know in the end I will need to get that from the caps statement but this gives me a head start.
Michele Mottini (May 01 2019 at 13:41):
Don't have anything publicly accessible yet (and our R4 server supports only Patient and Encounter so far)
Brian Reinhold (May 01 2019 at 14:15):
Don't have anything publicly accessible yet (and our R4 server supports only Patient and Encounter so far)
Add Observation and Device and that's all I need ... oh transaction Bundle for uploading. The last might be difficult. We also use conditional create transactions to avoid data duplication (then we filter once we get server logicial ids). Personal Health Device can be very bad about uploading old data repeatedly.
Michele Mottini (May 01 2019 at 14:17):
We do support transactions
Michele Mottini (May 01 2019 at 14:17):
We have Observation and Device (to a certain extent) for DSTU2 and STU3
Michele Mottini (May 02 2019 at 16:05):
Our server is up at https://b3-notify-3900-consumers-notify.b3-deploys.com/notify.Adapter1.WebClient/api/fhir
(still working on some kinks on subscriptions)
Michele Mottini (May 02 2019 at 16:05):
@Brian Reinhold I can give you a login / register an app for you - or are you going to use backend auth ?
Brian Reinhold (May 02 2019 at 18:49):
Brian Reinhold I can give you a login / register an app for you - or are you going to use backend auth ?
I can support client credentials or username/password grants. I cam also support a scope parameter and separate endpoints for the token server versus the fhir server.
Michele Mottini (May 02 2019 at 19:03):
You should have received an invitation to activate your login
Brian Reinhold (May 02 2019 at 19:10):
You should have received an invitation to activate your login
Got it and created a user ... I think.
Should I use the username and password in the oAuth2 resource owner grant request?
Brian Reinhold (May 02 2019 at 19:49):
You should have received an invitation to activate your login
@Michele Mottini Okay, I tried. I got an oAuth error that I am not authorized to access the resource. I assumed the oAuth2 token server had the same endpoint address as the FHIR server. It took a very long time to type in that URL on my little mobile phone!!!
I assumed you are using my username and password as resource owner credentials (a username-password grant)
Michele Mottini (May 02 2019 at 20:43):
The OAuth urls are in the FHIR conformance
Use client ID 'FHIR' - no client secret
Michele Mottini (May 02 2019 at 20:43):
And yes, use your user name and password
Brian Reinhold (May 02 2019 at 21:00):
@Michele Mottini
Oh.. So I need to parse the capability statement for the oauth URIs. That will take a while to write that code. Can you give me the url so I can just enter (and test) it at this time?
I am a little confused. When using resource owner credentials I pass a body in the oAuth request containing the password type of grant. Something like this:
grant_type=password&username=BrianReinhold&password=myPassword
If I am using client credentials then the body only has
grant_type=client_credentials
and the basic authorization header has the client credential and secret (base64 rncoded)
clientCredential/secret
Usually both are not done at once. Do you want me to enter BOTH the resource owner credentials AND the basic authorization header 'FHIR' ?
Michele Mottini (May 03 2019 at 01:51):
Yes, you need to send also '&client_id=FHIR' (I have not setup a client secret, so that's enough, no auth header)
Michele Mottini (May 03 2019 at 01:54):
The token URI is https://b3-notify-3900-consumers-notify.b3-deploys.com/notify.Adapter1.WebClient/identityserver/connect/token (you do not need to write the code to parse the capability statement .... you can just look at it)
Brian Reinhold (May 03 2019 at 09:03):
Yes, you need to send also '&client_id=FHIR' (I have not setup a client secret, so that's enough, no auth header)
@Michele Mottini I send the client credentials in the Basic Authorization header so it would look like this
Authorization: Basic FHIR (the 'FHIR' gets Base64 encoded of course)
So I am still a little confused as to what is being required
Using client credentials I would have the HTTP Basic Authorization header as above and in the body
grant_type=client_credentials
There would be no use of my user name and password
Using resource owner credentials I could have a either no Basic Authorization header but the body would be the password grant
grant_type=password&username=johndoe&password=A3ddj3w
So you want me to put the password grant in the body and the client credential in the Basic Authorization header? Shall that client_id be '&client_id=FHIR'?
Doing either approach gives me an invalid client_id response. It would help if you can sketch out what the HTTP request would look like, Basic Authorization and body as I am confused as to the type of grant being requested.
Maybe I should clarify:
I can only support the
Resource Owner Password Credentials Grant (4.3 in the oAuth2 standard RFC6749)
or
Client Credentials Grant (4.4 in the oAuth2 standard RFC6749)
I cant do the authorization code grant (4.1) or implicit grant (4.2)
Grahame Grieve (May 03 2019 at 09:45):
test.fhir.org supports web socket subscriptions on /r4
Michele Mottini (May 03 2019 at 11:39):
POST grant_type=password&username=BrianReinhold&password=myPassword&client_id=FHIR
Paul Church (May 04 2019 at 15:50):
The websockets section in the spec says "Client sends a bind :id message over the socket (using the logical id of the subscription). For example, the client might issue: bind 123)." - looks like that example should say "bind :123"? I haven't tested yet to see which the server actually expects.
Michele Mottini (May 04 2019 at 15:53):
The way I read it :id is the id - the colon tells you that is not literal
Michele Mottini (May 04 2019 at 15:54):
(We expect / use bind 123, bound 123, ping 123)
Grahame Grieve (May 04 2019 at 15:54):
yes that's how I implement it on my server
Brian Reinhold (May 05 2019 at 10:50):
To clarify, can someone put the exact string that needs to be sent given that I have obtained the subscription id from the server.
Last updated: Apr 12 2022 at 19:14 UTC
