You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We do not really need the combination recipes per say since we now have account linking related functions. This also makes dev experience better overall since they don't have to worry about double init of recipes unnecessarily
TODO
Node SDK
Golang SDK
Python SDK
web-js
auth-react
If the user enters a wrong email / phone (from a syntax point of view) in passwordless with phone or email mode, the error shown right now is "Email or Phone number is invalid". Is this coming from the backend as well or just the frontend? Cause this needs to change now depending on what UI is showing.
It's coming from the frontend by default and it is determined by the recipe/lang translations.
if it passed the validation on the frontend, the backend still validates it and returns the exact strings we display (it can be translated)
Make UI combination work for all cases
Refactor complicated code out
If the auth Ui has all factor ids, and the user clicks on continue with passwordless, it should not change the url (nor the query params), but just show the passwordless UI component instead, and that will have a back button (cause the factorIds in the url are not just passwordless specifc), and when the user clicks on the back button, it will show the original sign in / sign up UI again (depending on where they had navigated away from)
If the auth Ui has all the factors, and then usere clicks on passwordless and enters their emial, then they see the otp screen / magic link screen. If they refresh, they will continue to see that screen (the otp / magic link one). If they click on choose another email, it will take them back to the original auth UI (the sign up or sign in screen, based on where they started), and not just the passwordless login UI.
The query param in the auth screen will have if it's a sign up or sign in flow, and it will change once the user toggles sign up / sign in in the UI. This query param will be ignored in case there is no emailpassword based login to be shown.
The paths for email exists / phone number exists in emailpassword and passwordless have been updated.
We are introducing a new override provider to override the:
header
divider The divider component never used to be separately overrideable. It's easy enough to change through css. For more complex cases, the list display can be overridden.
auth component list
footer
Note that these will NOT apply to the enter OTP or magic link screen, HOWEVER, they will apply to the passwordless UI that is shown when someone navigates to "continue with passwordless" from the sign up page.
The component (to ask user to enter email / phone number before continuing) that shows up during sign in when dev has init emailpassword and passwordless, can be overriden via the passwordless recipe.
In terms of embedding, we expose an page, and it will get props:
of which factor Ids it should show. If none is given, it will just render all that is init
isSignUp prop which will only render the sign up UI only. If this is false, it will only show sign in, and if it's undefined, then you render sign in (or whatever the default ui to show is) with a switcher.
We actually always show the switcher, the isSignUp prop just sets the initial state. The switcher can be hidden in other ways (css/component overrides
This is similar to how the factor list works, sometimes it can change base
pre built UI list. The factorId input must be a subset of this list, and if it's not, the component will throw an error
This component will show the passwordless otp / magic link screen as well. Not the callback screen though.
The state of this UI (if the user clicked sign up or sign in etc), is usually stored in the query param in a full page UI. However, in case of embedding, by default we store it only in memory.
The MFA stuff is NOT a part of the component. That is OK.
FDI spec
new path for passwordless and email password
mark old paths for passwordless and email password as deprecated
New FDI versions: 2.0 and 3.0. Node will have both, whereas python and golang will have just 2.0. Frontend SDKs will have all of them as well. 2.0 will have the changes over FDI 1.17 + changes mentioned in the above points. 3.0 will have changes for latest FDI + changes mentioned in the above points.
Docs
Need to remove all the links that have rid in there
Dashboard testing
Example apps
We need to handle rid in email verification link, passwordless link and password reset link to remove them. So that it's backwards compatible with older frontends, cuase if the older frontend has thirdpartypasswordless for example, then the rid being passwordless will not work for it - will this work from a frontend backwards compatibility point of view?
is there anywhere in the sdk where we check if it's above a certain FDI, then do xyz - for example, it's there in determining how the user object looks like as a response of the sign in / up APIs. So it needs to account for new FDI version that is greater than the current one, but lesser than 3.0.
Link in dashboard (to swagger) to create a user needs to point to email password sign up, and not tpep sign up.
Changelog.md of backend sdk (golang and python) should mention how to fetch user info based on email / id related to checking the relevant combination recipes.
In docs repo, remove the && false from codeTypeChecking/index.js on line 564
add link to older tpep recipe docs and tpless recipe docs
passwordless email exists get bug in backend sdks
add tests for passwordless api logic change for node sdk
The text was updated successfully, but these errors were encountered:
Summary of issue
We do not really need the combination recipes per say since we now have account linking related functions. This also makes dev experience better overall since they don't have to worry about double init of recipes unnecessarily
TODO
dividerThe divider component never used to be separately overrideable. It's easy enough to change through css. For more complex cases, the list display can be overridden.isSignUp
prop just sets the initial state. The switcher can be hidden in other ways (css/component overrides&& false
from codeTypeChecking/index.js on line 564The text was updated successfully, but these errors were encountered: