Integrating known.email on top of other solutions
What to do if you as a merchant was using another solution?
This topic is only for those who are merchants. If you are a regular user -- i.e. one who uses our special inbox as a user only, then this topic is not for you.
The word "you" here indicates you as a merchant i.e. the person who is using our API The word "offering" means whatever SaaS/Software/Application/App etc where you allow entry of users from known.email
We already explained in the previous topic how to use our system if you are coding your own offering from scratch. But then you could be a SaaS provider for a software/solution already written by someone else. Or your code is already hardened and there is already a user membership system in place. This topic explores what you could do.
Prerequisites Integrating known.email into a previously existing membership system is not difficult. There are two mandatory preconditions that your existing system must satisfy
It should be possible to create a new registration into the membership of the earlier solution using an API call or by editing the back-end database
It should be possible to change the password in that membership of the earlier solution using an API call or by editing the back-end database
If the previous system did not have the aforesaid two conditions, then kindly pardon us: You will find it difficult to integrate the known.email system into your existing solution.
Luckily, in most well written SaaS applications, the above two conditions are usually met! Even old ones. Nowadays, many modern solutions have much more open-ended membership systems built-in; with lots of integration capabilities. You should be able to integrate Known.Email quite deeply into those very seamlessly. We are expanding this documentation; as and when we find ways to integrate those modern applications.
Do contact us on our Discord community, if you were able to integrate Known.Email into some previously written solutions. We will reward you with additional Koyns; and make your usage of our Known.Email system practically free for you.
In this topic, we are explaining how to integrate an old SaaS solution which only meets the above 2 prerequisites. The strategy we are offering here is one built on top of a reasonalby inflexible old solution. But realistically, it would be much more easier than this.
Integration strategy
Do the following steps
To handle the correspondence between Known.Email users and members of your earlier systems, create a database or if you do not have many users, your existing file system could itself be a useful "database"- just create suitable files for each user. Let's call this the "UN-database"
Do all the steps as explained in the previous topic -- Pretend that the "new application" here is to maintain the aforesaid UN-database! That means, the entry page where users enter their alias would be seen first; and it is used to check the user or enter the user into the UN-database. The login page of your existing solution would come in at a later step.
Once a known.email user becomes a member of your UN-database, invoke a procedure to check for the correspondence between the user in the UN-database and the member in the previous membership system. Your UN-database could have a name-value table to do this correspondence. If such a user is new even in the previous solution; silently register a new account by calling the previous solution's API/code. If the same user was existing in the previous solution, silently reset the password to say "yyyy" (this just an example. You should choose something the user can use; and is secure). If your previous system also needed a username or email address for the login; note that down. Let's call that as xxxx
At this point when your code is sure that the user from Known.Email can proceed entering your previous system, inform the user on the HTML page: "This page will shortly redirect. You should now use xxxs as the username and yyyy as the password . Click to continue..."
When the user clicks, redirect the HTML page to the login page of your previous system. As the password was reconfigured by you silently to "yyyy", the user can easily login there.
There is one small disadvantage: Ideally; you should reset that password silently once the user logs out from the system. That means, your code should replace the password "yyyy" with something else the moment a user has logged out-- that way the user is forced to once again start with the first entry page of Known.Email as explained in step 2. But often, it is hard to detect the "logout" of a software -- because the user may simply close the browser window (or the application) without really going thru a proper "exit" route. That means, the same "yyyy" password would remain valid for a future session too in your existing solution.
Last updated