Re-implementing E-Signet flow to mosip repository #23
Conversation
|
@PathumN99 you have done some great work so far. I just pushed a couple of commits. I changed the PORT of the esignet-mock to be one which wont clash with OpenCRVS client. Also we need to keep the fetch token request as E-Signet expects with the |
|
|
||
| /* | ||
|
|
||
| TODO: Understand from Tahmid about how to handle this: |
There was a problem hiding this comment.
@tahmidrahman-dsi can you advise how we can send this state and callback URL to E-Signet using the REDIRECT button please?
There was a problem hiding this comment.
@euanmillar Current implementation saves no state. But can be saved if the requirement needs. Before developing, it would be great if I have a bit more understanding from my side.
client_id=$openIdProviderClientId
response_type='code'
scope='openid profile'
acr_values='mosip:idp:acr:static-code'
claims=$openIdProviderClaims
As per my understanding, the above parameters are appended as search query params to the redirect url (esignetAuthUrl). And when the redirection is completed, eSignet forwards user to the opencrvs form url with param authorized=true which causes calling the callback url esignetUserinfoUrl. But you need those params for calling the esignetUserinfoUrl. Isn't it?
If my understanding is correct, does putting those params inside redirectCallbackFetch field's options field solve the issue? Please let me know your thoughts.
cc: @naftis
There was a problem hiding this comment.
You are correct to this step:
As per my understanding, the above parameters are appended as search query params to the redirect url (esignetAuthUrl).
After that though, the above URL redirects back to OpenCRVS with
https://register.mosip.opencrvs.dev/drafts/1234-1234-1234-1234/informant?state=same-that-you-supplied&nonce=same-that-you-supplied&code=authorization_code&error_description=in_case_of_error_this_is_sent&error=error_code
The onmount-fetch should be able to be configured so that for example a ?code=.. exists. To the ?state=.. we can set anything that E-Signet sends us back as-is, so we could put something like "?state=trigger-onmount" there to be explicit. So yes, we can use these parameters instead of authorized=true. This code is then used to fetch the details from @opencrvs/mosip/server, which then again fetches the userinfo from E-Signet.
https://docs.esignet.io/integration/relying-party
The full flow described above is documented here.
There was a problem hiding this comment.
@tahmidrahman-dsi @naftis my question was, how does the REDIRECT button know the draftId in order to format the state URL query param so that this works with mock-authorizer HTML which appears to need it like this: const params = new URLSearchParams(window.location.search); const opencrvsDraft = params.get("opencrvsDraft"); const opencrvsFormPath = "{{CLIENT_URL}}" + "/drafts/" + opencrvsDraft + "/events/birth/child/group/child-view-group"; const destinationURL = new URL(opencrvsFormPath); destinationURL.searchParams.set("authorized", true); window.location.replace(destinationURL);
There was a problem hiding this comment.
https://github.com/opencrvs/opencrvs-countryconfig-mosip/pull/1/files#r1905329313 Referred to this question here
packages/server/package.json
Outdated
| @@ -13,6 +13,10 @@ | |||
| "envalid": "^8.0.0", | |||
| "fastify": "^5.0.0", | |||
| "fastify-type-provider-zod": "^4.0.2", | |||
| "jose": "^5.9.6", | |||
| "jsonwebtoken": "^9.0.2", | |||
| "node-fetch": "2", | |||
There was a problem hiding this comment.
I'm not sure we need node-fetch with a recent Node version? The country-config package might need it (as @types/node-fetch) as it's exported into the country-configuration but otherwise we could be fine with the default one
There was a problem hiding this comment.
So that we can test the server as standalone before it is merged into opencrvs-countryconfig-mosio, I think we should leave it in and remove later.
There was a problem hiding this comment.
Made it a devDependency. Is that OK?
There was a problem hiding this comment.
When running locally standalone, we can use the Node's native fetch? And when the country-config uses the Docker image of packages/server, the contained image also can just use the native fetch? I think the country-config itself isn't running this code as is, if I understand this correctly
euanmillar
added
💅 Waiting For Review
| node_modules | ||
| .secrets | ||
| .turbo |
There was a problem hiding this comment.
👍 nice, please introduce Turbo to me!
| PORT: port({ default: 20260 }), | ||
| HOST: str({ default: "0.0.0.0", devDefault: "localhost" }), | ||
| CLIENT_URL: url({ devDefault: "http://localhost:3000" }), | ||
| }); |
There was a problem hiding this comment.
| }); | |
| }); |
hmmm have I might have forgot to install Prettier to this repo. I can action on that
| const searchLocationFromFHIR = (name: string) => | ||
| fetchLocationFromFHIR<fhir2.Bundle>( | ||
| `/locations?${new URLSearchParams({ name, type: "ADMIN_STRUCTURE" })}` | ||
| ); |
There was a problem hiding this comment.
We need to add an issue to refactor this to use a GraphQL endpoint, or something else than directly querying Hearth: but for first version to just get everything working it's fine.
Locations... 🤯 🤔 🤔
| }; | ||
|
|
||
| const pickUserInfo = async (userInfo: OIDPUserInfo) => { | ||
| // TODO: refactor using shared IDs and leaf level search using Barry's work on Uganda |
| @@ -8,6 +8,8 @@ import { mosipHandler, mosipNidSchema } from "./webhooks/mosip"; | |||
| import { opencrvsHandler, opencrvsRecordSchema } from "./webhooks/opencrvs"; | |||
| import { env } from "./constants"; | |||
| import * as openapi from "./openapi-documentation"; | |||
| import { getOIDPUserInfo, OIDPUserInfoSchema } from "./esignet-api"; | |||
| import formbody from "@fastify/formbody"; | |||
There was a problem hiding this comment.
Got an error for a fetch call which uses content type application/x-www-form-urlencoded. This is a plugin for Fastify that adds a content type parser for the content type application/x-www-form-urlencoded which resolved the issue. Wonder whether there is a workaround for this.
There was a problem hiding this comment.
Makes sense, but where do we make a fetch call using application/x-www-form-urlencoded?
There was a problem hiding this comment.
It's in the fetchToken function here.
There was a problem hiding this comment.
Probably makes sense to just change that to be application/json. Not sure why it's www-form in the first place :o
#7980
opencrvs/opencrvs-coreGateway OIDPUserInfo logic into the server folder ofopencrvs/mosipTODO:
TODO in next pull request: