First 250 days of software dev - Part 17
12 min read
Day 161
I've learned more about the steps I need to follow in single sign on. Although I haven't thought about every part in detail, I'm trying to follow and code a scheme on how a simple authorization and verification should be done. The problem I had today I couldn't solve at the end of the day. When a server sends a request to another server with the post method and wants to get the response (using axios), it can get the response without any problem when receiving normal and ordinary variables, but it cannot get the session information. However, session information can be accessed from everywhere else on that server. Even when retrieving data from that server with the get method, the session data is simply accessed. Tomorrow morning I will refocus and try to find the main source of the problem and solve it, or alternatively I will solve it with the get method. In addition, I transferred the transitions from the redirect method provided by express to a different url on the client side in the normal way. Everywhere I use it. Despite that, it continues.Day 162
I fixed the problem I encountered yesterday in a hackish way with your statement. But then I encountered the same problem again and I tried to understand exactly what the problem was caused by. I could add data to the session when I was processing a post request from the same domain address. There was no problem with the get request from the same domain address. But even though I could perform operations with a get or post request from a different domain, I could not save data to the session. I thought that if it allows me to perform operations, it allows CORS. But if I cannot add data to the session, I thought that I could not get the result I wanted because it is a precaution against CSRF. So I will look at it tomorrow morning.Where am I?
If(user is not authenticated) Domain A-> Domain B; //This part has not been coded yet.
//Domain B first receives and verifies the login information from the user by using the parameters from Domain A. If it is correct, it sends an authorization code to Domain A. Domain A sends back the auth code with client id, client secret information in return. Here Domain B creates the necessary tokens. Why didn't it send the necessary tokens (id token, access token, refresh token etc.) directly? Because if there is a part to authorize depending on the user's permission, it is ensured that the user knows the scopes that the site wants. This does not need to be in the current system, but I added it this way because there are examples I have seen (can be deleted or improved). Then, Domain A uses the id token to see the user information (the id token is sent if Domain A has specified it in the scope for authorization (as used in openid)). The access token is only used to access the areas where authorization is available (For example, when we want to get data from different source servers, we can see what our authorizations are when we want to access those resources. Originally, Domain A should not be able to read and understand the access token. To ensure this, instead of using a symmetric algorithm like hs256, an asymmetric algorithm like rs256 can be preferred. Actually, it may not, it is a matter of preference as far as I understand). Today I finally created the tokens as JWT tokens and they can be read both in Domain A and Domain B with client secret. The problem is that when I send the tokens from Domain B to Domain A via post, I cannot write to the session. As I guessed it is a CSRF related issue, so I did some reading on this topic this evening. With the middleware here I don't know if I will be able to solve the problem, but I will look at this situation first tomorrow. In this article , I will try to pay attention to the recommendations and warnings that need to be taken into account. At least, it seemed necessary to keep them in mind.
What I have to do next: The problem in this case is that I always wanted to prefer the session. Actually I need to keep some information in the cookie (like whether the user is logged in or not) because when the user closes the browser the session is completely deleted. I understand that it is possible to prevent this by changing a parameter, but I can't remember it clearly at the moment. If necessary, I can also save the relevant data in the cookie or change the session settings.
In general, what I need to do afterwards: When the user enters a different domain address (on the domain I am interested in, on the domain I own), first the cookie or session is checked. If there is no required user information, it asks Domain B, that is, the auth server, if the user is logged in. If not, it continues its operations from where it left off. It does not disturb the user. (If the user logged in to a different domain, the auth server would have the user information in the session or cookie. Therefore, the current site would also be logged in and the necessary information would be given to this domain address).
In short, I still have some work to do on SSO. But I can say that I have a better command of the problems and what I need to do. I just think that I should use the tools I use more efficiently in the areas where I get stuck.
Day 163
I couldn't complete the fiction I was working on today. Either there is a problem with my fiction or I can't overcome the technical problems, even though I try the possible solutions in every source I see. I think I can't get the result I want because there is a mistake in my fiction. I will try again. Honestly, even if I feel sad or cry when I can't do what I want, I will continue to try, learn, and learn lessons.Day 164
I didn't get where I wanted this week, but that doesn't mean I'm going to fail in my mission. I'm going to do it, and that's why I'm going to work on it tomorrow, because I want to do it. I wrote the code that you showed me, and it's working fine. Tomorrow I would like to write my own setup on top of it in a nice way and add it like a piece of a puzzle. 95$ is paid, but I really don't know how to pay you right now. Before I started working at the company, I was talking to a friend of mine who was also interested in PHP, wordpress, etc., even when it came to OOP, MVC, etc., he used to talk about it as if it was extremely difficult things (mystical and divine things that are the result of decisions made by Greek gods), but he hardly knew it himself. Talking to him today, I realize the difference between a person who was a bit more interested in the subject than me back then and the person I am now. I'm always beating myself up, thinking that I don't know anything, no matter how many things I'm dealing with. But when I talk to someone who is not related to the subject or someone who is, I feel the difference very well. I just have a hard time talking to you. I'm glad I have a hard time. I saw a post on LinkedIn last night. Your GPA, experience, etc. (of course they are necessary for some criteria) are forgotten, but your connection with people, your relationship, your approach remains and is remembered. I think I will try to pay better attention to this not only in business life but also in life itself. I want to improve my appreciation of people, listening, understanding, loving, compassion and humility. I can do this "idly" because I feel a degree of comfort because of my connection with you.Day 165
Moving forward. The user was able to log in normally using the SSO server. From SSO only the necessary user information is given to the relevant client server(s). Only once idToken is created and clientSecret is shared in communication with the SSO server. Other than that, any user information that may be a security threat is not shared directly between the servers. Security issues can be fixed later. I have a bigger problem. It is a problem in the working mechanism of SSO, but I will solve it. When you log in from a different site, that site is redirected to SSO and SSO checks if that user has logged in yet. I always thought that I would keep the idtoken in the SSO's cookie and do the first check from there. Because if the SSO's cookie does not have idToken or any similar identifying data, how would I know that the user is logged in? It could be by keeping this login information in the database used by the SSO. I found it reasonable to keep it in both the SSO cookie and the database. I thought it would be healthier to keep the information about whether the user is logged in or not in their browser, but I could also keep this information in the database to compare against malicious intentions that could manipulate this. Maybe I am thinking in a complicated and wrong way. It can also be done by only looking at the IP address. Or it can be done just by looking at the cookie or the information in the database. The biggest problem now is to control the session from different client servers and save the cookies of those servers on the client side accordingly. The sweetest part of today was that I saved the client secret always changing. The client secret changes with each new login and it is also useful for security (The only way to unlock the id token is to know it. I think it's a nice little detail since all sites have one idtoken and one client secret).At the beginning of today, I systematically reflected my thoughts in the code, but then it was like a pig's knot.
What am I going to do tomorrow?
I wonder how accurate it is to keep idToken in the SSO's cookie. A site that has never added idToken in its cookie goes to the SSO to see if it has been logged in. The SSO checks if there is an idToken in its cookie and checks the idToken from the database or any other place where data is kept continuously and then supplies the idToken and client secret to that server. The most important thing is to provide a good protection against forgery (checking if it comes from allowed domains). There are no other problematic aspects.
In short, tomorrow I plan to complete the actual SSO part in rough. If I succeed, I will get into the fine workmanship.
Day 166
When a user who logged out of a site wants to log in again, I want to get his password and verify it and log in again if he confirms that he is that person after saying "hi GayeSu, is this you?" just like Google. Also, if he is not the person who logged in before, I want to give the standard form with the normal username and password. I was halfway through trying to do that. Finally, I'm thinking of adding the ability to log out of all sites. In such a case, I will need to add a middleware to the servers using that sso, to check and see if it has logged out from all of them.Tomorrow I will continue from where I left off. I'm going more systematically. The code is evolving and changing more than growing in these few days. If not tomorrow, I think SSO will be revealed in general terms the next day. It was the first time I worked so much with Node.js, I'm glad I did.
I learned a different information today, unrelated to the subject. "res.sendfile()" is used to send a stream of data when providing a file to the browser. What does this mean? Normally, I first use "fs.readfile()" to consume server memory, but this way I can deliver the file to the browser in small data packets, which is much healthier in terms of performance. Save the data in memory. Send it to the browser. Garbage collector does the cleaning process, in a way.
Day 167
I have tried all the possibilities I could think of in the first part of the task about SSO, only the vulnerabilities are definitely there. If there is a different big mistake and I haven't noticed it, I think I can fix it without much difficulty in terms of logical functioning. In SSO, all user login processes are based on the SSO server. The most important issue for the client websites that this server serves is the idToken they keep in their cookies. All user information is encrypted in idToken. The only way to read idToken is the data called client secret which is kept in the database common to client servers. This data is not fixed. At each login, 2 or 3 cryptographic encryption processes (first the client id and auth code are created in this way, then that data is used to create the client secret. I guess it is very difficult to guess) is created afterwards. If the user logs out from a single client website, only the session on that site is closed. The session on the other sites remains the same. If the user wants to log out from all of them, they are logged out from all of them via SSO (Client servers query SSO with a small middleware to see if all sessions are logged out). If only one website is logged in, other websites can also access this session. So SSO becomes meaningful. I couldn't test it fully because there is no second client, but it works as I want it to.While the SSO server keeps the user information and idToken in the database, the client creates its own user table in the server database based on the data provided by SSO. Only clientSecret related to authentication is kept separately for each user. User information is never transferred directly and all communication is done via idtoken, as it should be. The client server creates the client secret and transfers it to SSO only during the first login process and ensures that the idToken is created.
I was able to adapt to working in node.js, express, and node.js environment in general with this project you gave me. Tomorrow I will look at the socket issue as you said. First, I will list what I need to do by myself, imagine small sketches on how I can do it and try to realize my goals. After all the talk about OOP and design patterns, it makes me sad that I don't use any of them at this stage, but I think I will get there. I think what I am doing and trying to do is to build a structure that evolves rather than creating a human object in a single moment (God created it in 6 days, 14 billion years according to science?). Therefore, the desired patterns will also be revealed. I think a structure suitable for OOP and SOLID will emerge in the future.
Day 168
Today I moved the idToken logic from cookie to session, and while I was doing that I changed a lot of the code and made some extra improvements. I spent the whole day doing that. Now it is working as I want it to again. The reason for the change I made today was where I shouldn't keep some data. I learned "by doing" that it is wrong to keep some sensitive data in the cookie and I fixed it. I think I will never make such a mistake again.Tomorrow I think I'm going to concentrate on what I'm going to do with a different socket.io.
Day 169
In the first part of the day, I thought of copying the sample code and going through it as I did when I first encountered Socket.io. Then I thought I should design my own system and write accordingly using socket. The user who logs in using SSO will be presented with a front end just like skype / and other similar applications. Tomorrow I will give a basic view with rough html and css. I will write a similar to Skype at the simplest level using html and css and then I will try to provide data exchange using socket between client and server. Obviously, if I can do this without any problems, the only thing left is to implement this code using electron. And using a database instead of a text file. ORM or ODM can be used afterwards though. Most of the routing was the login part. The application will be almost like a single page application (not exactly, of course, I also used different routes in authentication).Nothing too difficult really, but I'm still too slow. I'm trying to speed up, for example most of today was spent fixing file structures. I didn't actually do much, but it still took me a while. I moved the authentication part to a different folder, and then I made some edits in the main javascript file about where to do socket-related operations. During this separation, I had some problems using middleware, but I got it the way I wanted it. It was these small problems that took me time, but I didn't want to ask you, I wanted to solve, find, learn by myself. It's like a baby who can barely stand, trying to walk on his own without asking for help from his parents, and even if he falls many times, he starts walking normally. With the wish to run, of course.
I shouldn't talk big, but I think next week the socket part will be finished very easily. Next week I think I'll use electron and apply this code structure there (what I do in client with Html and Css to electron). I think beautiful and sunny days are near.
Day 170
Today I worked only with html/css/javascript. The part I worked on is not finished yet, but half of it is done. I used variables in css for the first time today. I wanted to make a dark/light theme and it was very efficient to use css variables for this.In addition, when I use html, I always try to think about the big picture. I try to think about how I can reflect future data and relationships with the html codes I write. I feel the difference between the last time I used html/css and now.