Removing combination recipes

[rishabhpoddar]

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

• [x] Node SDK
• [x] Golang SDK
• [x] Python SDK
• [x] web-js
• [x] auth-react
  • [x] 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)
  • [x] Make UI combination work for all cases
  • [x] Refactor complicated code out
  • [x] 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)
  • [x] 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.
  • [x] 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.
  • [x] The paths for email exists / phone number exists in emailpassword and passwordless have been updated.
  • [x] We are introducing a new override provider to override the:
    • [x] 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.
    • [x] auth component list
    • [x] footer
    • [x] 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.
  • [x] 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.
  • [x] In terms of embedding, we expose an page, and it will get props:
    • [x] of which factor Ids it should show. If none is given, it will just render all that is init
    • [x] 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
    • [x] 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
    • [x] This component will show the passwordless otp / magic link screen as well. Not the callback screen though.
    • [x] 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.
• [x] FDI spec
  • [x] new path for passwordless and email password
  • [x] mark old paths for passwordless and email password as deprecated
  • [x] 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.
• [x] Docs
  • [x] Need to remove all the links that have rid in there
• [x] Dashboard testing
• [x] Example apps
• [x] 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?
• [x] 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.
• [x] Link in dashboard (to swagger) to create a user needs to point to email password sign up, and not tpep sign up.
• [x] 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.
• [x] In docs repo, remove the && false from codeTypeChecking/index.js on line 564
• [x] add link to older tpep recipe docs and tpless recipe docs
• [x] passwordless email exists get bug in backend sdks
• [x] add tests for passwordless api logic change for node sdk