Comments (3)
That is an interesting idea, but I'm afraid we do need a well-known location for our storage. Here is the gist of how that works for EHR launch (which is the most common):
- EHR calls our launch url with
launch
andiss
parameters. We are supposed to send thelaunch
back to the EHR andiss
is our FHIR server url. - We fetch some metadata from
iss
to discover the authorization endpoint - We check for an "old state" at our well-known storage location and remove it
- We create new random key for our storage and store it under "SMART_KEY"
- We redirect to the authorize endpoint providing the
launch
we have gotten and that random key asstate
param - The auth server may go through several redirects (for example to make us select a patient or to authorize the launch). Eventually we will be redirected to our
redirect_uri
with two url parameters -code
andstate
, wherestate
is the same random key we created earlier. - We use
state
to locate our runtime state in the storage - We use the fact that
code
param is present as a signal that we need to complete the auth flow by exchanging thatcode
for an access token - We remove the
code
andstate
from the url so that the app does not re-authorize upon reload (refresh or other user navigation) - After the app is launched and while the users navigate through its pages/routes, it has no way of knowing which storage key to use, unless it is stored in a well-known location ("SMART_KEY").
With that said, something you can try is (assuming your code works in browser):
// Do this fefore calling `ready`
FHIR.oauth2.settings.fullSessionStorageSupport = false;
FHIR.oauth2.ready().then(
client => { /* init my app */ },
console.error
);
This should preserve the state
from the auth redirect parameter in the url and the library should use it as a storage key. You will also have to make sure that the state
is preserved while navigating through various pages of your app.
from client-js.
Unless I'm misunderstanding I don't think the proposed solution would work for multiple clients. Because the library is checking for the state key either within the sessionStorage (using the hardcoded SMART_KEY where it gets set) or using url state parameter multiple smart clients still would not be possible on an app (they would override one another either in sessionStorage or on the urls parameters)?
My thoughts would be to instead allow a user to pass in a value during SMART client initiation that would tell the library where to pull/put the generated key in step 4. This would be a passed in parameter that would replace SMART_KEY where the generated key get's stored with another property and it would be the apps responsibility to store/know this key as opposed to the library. So effectively you would still be using a unique key generated within the library just where to find that key could be overwritten by the caller.
from client-js.
Rough draft of some code as an example that I think could work: https://github.com/smart-on-fhir/client-js/compare/master...parlir:client-js:upgrade_with_alts?expand=1
from client-js.
Related Issues (20)
- Unable to authorize using PKCE HOT 2
- Typo in README
- Unable to get patientId after successful login HOT 1
- (Error handling skipped on init) CompleteAuth not triggered for init HOT 1
- includeResponse not working for FHIR update operations
- "target: popup" (etc) demos don't work in current Chromium HOT 2
- Single SMART_KEY breaks authorization of several users on server-side
- Jest + RTL :: Testing with FHIRClient
- Uncaught (in promise) Error: Failed to fetch the conformance statement from "https://staging-fhir.ecwcloud.com/fhir/r4/FFBJCD/metadata". TypeError: Network request failed HOT 6
- Question: Smart-On-Fhir implementation inside Service Worker
- FHIR type Meta requiring lastUpdated property when spec allows it to be optional
- Node js After 10 min 401 unauthorized response HOT 4
- Window closes itself when it's not actually a popup
- Save token info in DB
- Support of PKCE even when the EHR .well-known configuration is not set? HOT 2
- Assumption on patient id in context
- Improve or rename "Contributing and Development" section in README
- Zombie `changelog.md` file in the project's root.
- npm audit report semver vulnerability
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from client-js.