nango
nango copied to clipboard
new session param: final_redirect_url
New parameter for connection sessions: final_redirect_url
This param enables starting a new connection creation that finalizes with redirecting to final_redirect_url
with error or success result. It especially frees developers from frontend SDK dependency to create connections.
Frontend SDK typically builds connection initialization URLs like this: http://127.0.0.1:3003/oauth/connect/my-service?connection_id=test-connection-id1&public_key=b9ad10b6-4283-4f7e-a377-82279ad54a4f
Nango users can also use this URL to initiate connection sessions without using frontend SDK, however, there isn't an easy for them to finalize the connection process without using websockets or popup windows (to be notified via window.parent.message
).
You can now build connection initialization URLs like this: http://127.0.0.1:3003/oauth/connect/my-service?connection_id=test-connection-id1&public_key=b9ad10b6-4283-4f7e-a377-82279ad54a4f&final_redirect_url=http%3A%2F%2Flocalhost%3A5678%2Fwebhook%2F217fd5a6-190e-4659-95df-e78ff7fd48f8%3Fmy-external-param%3Dyes-correct
See the last final_redirect_url
parameter. That can be any URL and can include query params. Once the connection process finalizes with error or success, the authorizing user will be redirected to this URL, at which point you can continue using the newly established connection (or handle error experience).
Checklist before requesting a review (skip if just adding/editing APIs & templates)
- [X] I added tests, otherwise the reason is:
- [ ] I added observability, otherwise the reason is: not sure what to do about this
- [ ] I added analytics, otherwise the reason is: not sure what to do about this
hi there, do you need anything from me for this PR?
Thank you very much @oytuntez for your contributions. Could you describe the reasons why you don't want or cannot use the Nango frontend SDK? What is the flow you would like to achieve that is not currently possible?
Feel free to ping me on Slack if you don't want to discuss about those details publicly.
I am positioning Nango as an authentication provider for a larger integrations system (think of n8n workflows). So Nango would NOT be part of a user interface in this specific integration flow, just an authentication layer, which should let the parent system know if a user was successfully authenticated. There is no frontend involved in this user experience, simple redirects + workflow executions.
I hope this makes sense. I can also demo you in a call if necessary.
But the gist of my PR is this: if you can do something in the backend, why enforce frontend clicks. This enables many other integration opportunities without user being present to click a button.
@oytuntez I'm sorry for the time it took to get back to you.
We really appreciate your contribution and the time/effort it must have taken.
Unfortunately, after discussing with the team, we are not ready to add an alternative way to trigger the API authorization for the following reasons:
- This has not been requested by a significant pool of users. People have usually found ways to embed the frontend SDK, even on very simple web pages. We would have to take this alternate flow into account when we update/maintain this core part of the product, which we don't have enough resources to do.
- We would have to estimate and potentially mitigate the security implications of redirecting end-users to an unverified URL.
I am very sorry that we cannot add this feature just now, despite the work you've put into it. Next time, please reach out beforehand and we can let you know if your planned contribution aligns with our roadmap or not. In the meantime, I would be happy to work with you on finding a workaround (you can just reach out to me on the community).
As a result, I'll close this pull request for now and keep you posted when/if we make this change.
Thank you for taking time to explain your perspective, @bastienbeurier! I understand your points and find them valid for your case.