 All right guys, does this work? Can you guys hear me? Okay, so I sort of was taken by surprise at finding myself in the entertainment slot because whoever does a 2pm talk has to get everybody awake again you know, it's a It's a bit of an interesting challenge because I've also spent the last two days Helping the crew here set up the video stuff which meant that there was time. I was not making my slides. So let's see how this goes All right, so just give me a sec I'm going to put out an example on screen that I'm going to use for a couple of things So it's also the first time I'm presenting with this device. I'm going to find out how well it works So let's see. Let's come back on the site Okay, so how many of you voted on the funnel for talks this time? So that's about half the people in this room and do you guys remember the login screen that you saw when you voted? It asks you whether you want to go to Twitter or Google. That's what we're talking about. We're talking about how I built that and what I learned in the process of building that and So basically among the lessons that I figured is when I started doing this I went in Trying to solve a login problem once and for all and the reason I did this is I build multiple websites. I Organize events the same way that like by con and every event has its own website And the problem now is that if you want to register a user and you want to use that account Not just an email address and name an email address But you want an account something that they can use to log back in and work with this site trying to do User management across multiple websites basically means that you're making people make accounts multiple times And they're just silly you want them to say you made an account once use it again And the best account is one you don't have to make at all. You just use Google or Facebook or Twitter or whatever else So basically I went through a series of learnings trying to do this starting from 2011 I also gave a talk at Picon 2011 about this project. I'm not going to repeat what I did over there What I'm going to do instead is what I've learned in the period from 2011 to 2014. So In 2011 I figured I'm just going to Find a simple way to help people register accounts. It's a you would think that making accounts is as simple as this all you're doing is I That the user can register an account log into an account Reset their password verify an email address So you know that they could capable of receiving email at this address maybe verify a phone number and that's about it and maybe you want to make it easier and Provide them log in with Twitter Google or some social media service. So In the process of doing this what I learned is that in reality Making an account is about understanding identity and representation. These are not technology problems These are user behavior problems and they come back to bite you as technology problems If you don't understand how user behavior maps to your technology decisions. So I'm going to go through this so when I started trying to do federated entity I looked at what was available and what was available for cross-site entity and Open ID for a long time had been touted as one solution I spent some time studying that realized that open ID was actually completely horrible it's going to cause a lot of problems for people trying to use it and One of the clearest examples of where it's gone horribly wrong is a stack overflow Stack overflow has stack exchange, which is a centralized login mechanism You can use open ID from a variety of services to login, but you look at the login dialogue Can any of you guys remember what you use the last time you used stack exchange So it takes extra effort on your part try to remember and say I remember I used my Google account last time and not my Facebook account, so This is basically what I learned in the process now the fundamental notion of Logging in is about saying who are you? You're trying to tell the computer. Hey, I am Kiran John Legada and I'm back and I'm trying to log in now The problem is who is this guy? so Let's say that I want to just log in and say hey look I'm Kiran. I want to log in now the problem is You need to provide a unique identifier and say this is the identity that I'm using to log in that Nobody else in the world has because that's the only way to say that I'm the guy who's actually coming back You can't use your name. That's very well established. You search online They'll always be somebody else with your name no matter how unique you think it is One thing that works is generally using an email address And so this was a lesson that Amazon learned way back in 95 when they started doing e-commerce and Essentially until then you had user names, which is basically what you used to log into a computer shell, but in 95 Most people did not use Unix. They used Windows Windows booted you straight into the desktop So this idea that you log in Was a fairly unusual concept for people coming online and realizing that there is some such thing when they go to a website And so Amazon figured They're not going to ask you to make an account with the username They just going to say please provide your email address and maybe set a password against this email address and that's it So they did a clean job of doing that There is a problem when you do that I'll come to that Now if you look at say Twitter on Twitter you have user names Very obvious right in Twitter your username is not just the way you log into Twitter. It's how people know you That it's not enough to have your real-world name online You need to have a unique online name that exists only within the service and that is your identity in the survey It is your actual name. This is how people know you so Twitter has essentially convinced you to say that Make up this new name for yourself and remember it forever And how do they do that by making sure all your friends address you by that name? Because that's the only way that they can talk to you on it So basically they help you understand that this is your identity now. It is not just a login identifier now Google on the other hand did not have accounts until about 2004 if you guys remember trying to say Google preferences Back in 2003 it would essentially save it in a cookie and just save it in a browser and that was it There were no user accounts in 2004 they introduced Gmail Gmail for the first time required user accounts and Google also wisely decided that most people cannot remember strange names. So they said please use first name last name at gmail.com and Make it easy for you to remember because it's first name dot last name Use that now Google Did that seem like a sensible decision back in 2004, but more or less since learnt so email has an unfortunate problem If you put your email address out in public you get spam, so if you want an identity That is about saying this is me and here are my contact details on this website Here is how you talk to me you actually get afraid of putting your email address there Because you really do not want to be spam now the spam problem these days is more or less resolved It's very well tackled by most anti-spam tools But that was not the case for at least a decade for at least a decade We struggled with spam to the point where we would be very very careful of putting email address out or obscure them in various ways and so on so what happened there is Google had an account system like Amazon that depended on your email address Twitter and other services basically forced you to make a completely new identity Facebook copies the Twitter model eventually when they introduce usernames now Google essentially went on to launch Google plus which is the first social network in the world where they have problems like this again Let's get to that so What Google plus realized is if you want a friendly URL to your profile page What is in the URL in Twitter Twitter comm slash username? Google plus plus Google comm slash what? your email address You can't put an email address see Google basically created an identity system Where the identity system was unusable because it was an email address So they had to then queue random numbers you get some random hash a number that nobody can remember and In essence when you start depending on an email address as someone's identity It's easy for them to get started because almost everybody remembers their email address But then you can't go build a social profile on top of it We need to now force them to create a new kind of identity Which is a little confusing for you people who you have not taught this right from the beginning so This became one of my pain points the other things that you learn is Does one human have one email address Obviously not This is the part where Google wasn't really thinking very hard because when they introduced accounts in 2004 Until you had Gmail you had no user accounts when you had Gmail your Gmail account became your Google account and it's basically gone all the way from there saying that your Gmail account is now your Google plus account and Basically, that's how you get to the situation where in Google Gmail in Google plus Because they cannot identify a human by more than one email address Every single email address of yours becomes a separate Google account and therefore Google plus is the only social network where you're two humans at once Okay, and this is a basic design problem that when you assume some things about how the relationships work between email addresses and people so When I started building last user this was one of the lessons that I already had the foresight of looking at because somebody else It's screwed up already. And so what I did is set up my user account model saying one You can have a username if you feel like having a username. It's optional To you can log in with either your username or email address. Whatever you prefer 3 use your Google or Twitter or whatever social profile that you have although that caused me more problems later on and For Identify verify the email address when somebody says this is my email address We send them an email with a verification link. So you please verify this is your address if you don't verify it We don't believe you so anybody can claim any email address, but until you verify it. We don't believe it's yours Okay, once you verify it nobody else can claim it. So that would seem like It's all the problem But then you get to this problem Is one email address only one human anyone willing to So is some question in the room He's not so some question and his wife Runa for a long time had a flicker account that said Runa and Sankarshan two humans in one account Behaving like one person for all practical purposes Sankarshan's removed Runa's name from the account for some reason But the user name still says Runa and Sankarshan go look it up now The thing is in this case, it's two people sharing an account Consciously behaving like one person within a service because they understand that things will break down if they behave like two people Yeah but What happens when you do this? This is an email address that goes to about four or five people We are all separate individuals. We are not trying to behave like one person In this case, it's a shared address. You can verify that I receive mail at this address You cannot use it to say this is this person Where is this a problem? Suppose I add this to my account the next per guy who's receiving mail at this address can use it to hijack my account and That means your account is not secure anymore So now we have a security problem when you trust an email address and say any mail address belongs to a person And now I don't have a solution to this problem This is one of the things where you look at this and say no matter what you do something will go wrong in your architecture so the The ways you deal with this is You understand that a person is different from a group and you build in mechanisms to deal with it. Don't do it like this If you look at github on other hand, they have actually thought this over very carefully If you look at the terms of service for github, it says your login may be used by one person a Single login by multiple people is not permitted So very clear One account has to be one human only One human can only have one account Yeah They make this very clear from the beginning Make sure you please do not do this Google press kind of nonsense where you have two different people behaving One account or two accounts for one person and so on Let's have a user account separate from an organization account and the organization account can be shared by multiple users And we come up with different permissions models for that and so forth So unfortunately most of the services don't really have an answer to this problem. They basically either Willfully ignore it like Twitter where they don't really care who you are You just have an account. It doesn't matter if the account is a company or the account is a robot or the account is a human It's an account or you have Google plus where they're completely confused so Now once you get past all of this You have to deal with the next set of problems How long does your email address last? So in 2011 you had a email address from your company in 2014 If you are still at the same company, you are extremely loyal most of us are not like that, which means your email address no longer works Okay, so now this is a problem when you make an account on some service with this email address now normally what we do is We have learned from bitter experience to never use a company email address for anything apart from company work Because it will not be accessible once you leave So you always sign into online services with a personal account and make this a thorough habit Now how many here don't really believe in this you always go sign up with your company account Nobody does he's joining a mailing list. You're joining a social network You're joining anything you always use a personal account because you want to guarantee long-term ownership This works until at some point. You're suddenly representing your company now for instance I happen to run a job board called has job and has job was built before last user So at the time I built it I went very very carefully through my architecture to make sure there were no user accounts at all because I did not want problems caused by user accounts and Essentially on the job board when you post a job you provide an email address and say that this is the address to which all resumes must be sent and That address then gets an email with a link that says click this link to edit the listing or to delete the listing And that's basically it if you don't have the link you can't do anything with this listing And Eventually I had to retrofit it and say okay now that I have a proper account management system Let's add it to the job board now the problems come in from the fact that when you post a job You are representing your company. You will use a corporate email address Okay, and when you create a corporate email address and use it for the service Suddenly now people get confused should they make this a separate human account again? Where in this is Kiran Zolga at home and this is Kiran Zolga at work Or do you say I just want to add this account to my is the email address to my account People get extremely confused when you are asking them to make such decisions Mostly because they don't understand the idea that they have an account most people simply do not like thinking about accounts as something that they consciously do and So you get problems Like this Yeah, the sign-up page I was trying really hard to avoid this problem of users creating duplicate accounts and you invariably end up with this problem again Simply because users do not remember that they made an account They can't remember what they used last time. They're going to click one and see maybe it was this and Then they come to a sign-up page which asked them for a little more detail and then they say oh shit This was not it now go back go the other way but in the meanwhile you already just made an account So if you go look at my account database It's littered with people having two or three accounts because they just can't remember what they did now the show more thing Initially used to be fully expanded This was the point where I had this moment of awakening saying please do not offer options that confuse people Use the two most frequent ones that people have been using so far hide GitHub hide LinkedIn hide everything else, you know Now when you come to this Eventually you have to address this problem people get extremely confused about this If you have submitted a talk on the funnel How many if you guys here submitted to speak at a pycon or a has weak event? so Now one of the things that people tend to do and I'm not saying you guys did it But a lot of people tend to do is they intentionally make a second account to go upward themselves If the Python selection team selected purely on the basis of our ports you're guaranteed that it's been gained By people making fictional accounts just to support themselves I know this because I have to debug problems caused by this kind of situation. So What I have been trying to do is do account merger at the database level This is extremely scary Because there is no undo When you merge an account and there's no undo because it's a fairly complicated database transaction But I have actually done this. It's incredible. I will show you the code just because it will not make any sense to anyone here Now So let's say let's let's just let's just look at the code. Okay Most of you who have used last user, which is something that you have actually used if you Submitted to pycon or voted on a proposal, but this is basically the code I'm going to jump to the relevant parts Now what this essentially tries to do is automate the process of merging accounts as much as possible This is the basic function. I don't think you can see it very well. Let's see if I can zoom in So what it does is that the instance is the current account Are there is other account that you want to merge into and you're trying to say Find everything in the database that is linked to a certain user and re-associated to the other user and then eventually discard this user Now what I have done in this case. Now, this is all Python code This is all written around SQL alchemy. So and because it's a library. It is not an application This is a library that is used by all apps that talk to last user It essentially has to be able to discover the architects of this database Figure out where the foreign key references are and go correct all of them. And what it does here is first it looks for The column that is being referred to in the SQL alchemy structure Keeps track of all the tables has been migrated and tries to figure out the SQL alchemy base class So how many of you guys here know how new style classes work? Your Python program is right. You understand that there is something called a new style class in an old style class Okay, one of the nice features about new style classes is you can essentially do This You guys understand what this line does a base class has subclasses method Which if you call returns a list of all the classes that derive from this base class Python allows you to inspect a base class and pull out everything that has ever been declared that is based on this base class So what I'm doing in this case is discovering the base class that is used for SQL alchemy models Find every single class in your Program that is a model because it is derived from this class Then go look it up for does is refer back to the user table and go fix it up. So what we're doing here is to say discover what the User table contains for discover the base class first keep iterating through one models base classes until you come to the root base class that is used for SQL alchemy then use that to go do migration and In this case we say that if the class happens to have a helper method for migrations use it Otherwise, we'll try to do it ourselves now I'm sure I've lost you here because this is not a Funny code, you know, it's scary. It was really scary for me to write it because I no idea what I was doing half the time But what in this case I do is go find the table that is referred to by this class Look at all the columns in the table if this particular column happens to be a foreign key to the user class You got it now. You need to change the value in this column Anytime this particular column has a reference to the old user's ID number change it to the new user ID number And then you're migrated it except when you have a unique constraint Like when you abort You're only allowed to abort a proposal once If you have afforded your proposal from two different accounts and eventually you come to the point where you're trying to merge These two accounts you can only keep one upward Which one do you keep? Now this is easy because I put it twice you can just discard one and be done with it But suppose you were trying to use the job world and you submitted a job application to an employer You're only allowed to apply once to a job And now you merge your accounts and you had two job applications. Which one do you lose? The older one, but how do you know? How can you make the judgment call? Remember, this is a dumb program that knows nothing about the intended use of The software. It's simply saying I'm trying to fix a database model here Somebody accidentally created two accounts. I want to help him merge it. So there is no easy answer to this So the automated thing basically says If it is unique, don't touch this model Ignore it more on to the next If you find that there's a primary key constraint or a unique constraint Your automated process of migration cannot do anything about this. This is now the application developers call How do you want to define user behavior and merger and so forth? And so what we do is we keep track of Whether it is safe to remove this instance because we do not encounter any unique constraints If it is then your merger is successful. You remove one account if it is not Merge it not successful you're migrated most of the data But some data could not be migrated because you encountered a unique constraint that you didn't know what to do about so the reason I'm going through all of this detail is Because of this This is basically what happens when you Create a user interface construct that you thought was friendly for the user but in fact caused more problems and the only way to solve this problem is by doing complicated database migrations and so on so The other way to deal with this is to simply say what if the user just never logged out If the user logs in once keep the session permanent If they did not log out, there's less likelihood that they'll accidentally created another account And this is somewhat the Facebook strategy that on Facebook you never log out once you logged in it stays there now this also happens to Be something that for a very long time was considered bad behavior in an application For a very long time. We believed that computers could not reliably be linked to one person If it's a desktop, it's going to be shared by whoever sitting at the desktop right now. You cannot assume that If somebody logged into this website, they want to remain logged in forever So for the longest time the way we have done login sessions is you always log out when the browser closes And that's basically by using session cookies Okay, if you want to now turn this around and say you want to log in forever This is essentially a change in usage patterns of computers that has happened in the last ten years that most of our you know best practices documentation hasn't really accounted for that these days you want to design your applications to never log out Unless the user wants to log out browsers now have an incognito mode or a private browsing mode Which is what users supposed to use when they do not want to remain logged in See if we put it around earlier it used to be the application developers responsibility to ensure log out at closing of the browser Now it is a user's responsibility Okay, and this is something that users have started to accept But if you want to now turn this around and say you're going to change the way your software works To deal with never logging out Then you also have to deal with the fact that there are other complications that come up in this and one of them is database sessions So let's go digress briefly into looking at how authors worked for the long time In the beginning there was HTTP basic auth now who do you hear remembers how this works? Does someone want to go for it? Yes, I have a mic so I Don't want people falling asleep at this point and I'm not got much more material left. So guys hand mic So there's someone in the back there who had wanted to talk about this Yeah, so let's get you on the mic so everyone can hear this It's just sending the username in the password with the HTTP request itself It's still done by some websites where you get a alert prompt saying what you're using you get a browser alert point not a HTML page, but a browser dialogue. It's an OS level dialogue that comes up saying login and password now the way this works is essentially on the server when you want the user to log in Normally you return a page with HTTP status 200 in this case you return it HTTP status 401 Which is authorization required and 401 makes the browser throw up a dialogue that says please enter your login and password okay, and The browser sends back whatever you type in if you accept it then you return it on it again If you don't accept it return a 401 again Except when you do this from now on every single request ever will have the username and password in the HTTP headers unencrypted and That basically means anybody sniffing traffic and simply read it off the headers and they have your login and password and this used to be standard practice in Most web application frameworks as recently as 10 years ago in 2004 Zopin Plone where by far the most popular Python web frameworks Pylons and Django and everything else was yet to come and this is how they worked that you do a HTTP 401 based HTTP basic auth Browser sends username and password and it's there in every single request ever after until the browser session closes and How do you log out? Has anyone tried logging out with HTTP basic auth Send another bad request. What happens then? Yeah, so he's right So basically what happens here is you send a 401 even though it's a correct login and password The browser will put out one more dialogue saying please log in again And this is when you say cancel and once you hit cancel on the dialogue the browser will not send a login and password again so Basically, you have to teach a user that to log out you have to See the login password again and not enter anything now try educating users about this and say this is how you're supposed to do log out not going to work so So the web community at this point had this had to find a way to deal with the situation and say this HTTP basic auth Is not user friendly Okay, people do not know how to reset passwords because the dialogue offers no option for this They do not understand how to log out. They don't understand why log out is showing them a login prompt again And so you say discard this Let's actually build our own infrastructure for doing this And so what we did was use cookie-based authentication where you do a HTML form now And the HTML form can have additional options like forgot password and whatnot and when you submit Save the username and password in a cookie Maybe base 64 encrypted because that was what encryption was for most people back then But essentially it's unencrypted. It's in clear text. It's going with every single request your browser makes again Okay, I'm not sure who invented this idea of using a cryptographically signed token at this point but it came up roughly about 10 years ago and I'm sure you guys already know this if you use Django or flask or pretty much anything This is how they work nowadays that you use a type 3 cryptographically signed tokens who wants to try explaining this Anyone guys, it's it's dirt simple and I'm sure you use it even if you don't understand it go over again You have the mic There are you you don't actually encrypt anything It's encryption can be resource intensive. So you simply sign it so so the way this thing works now is When somebody logs in once you confirm that the login and password are valid and this pillow is allowed to log in What you do is set a cookie which has only the username and Then sign it sign it with a cryptographic hash So when this cookie comes back the next time you can verify that this was set by the server It is not set by the client the client did not simply say I happen to be somebody else So you don't need to send a password back every single time you simply need to send a signed token that is referring to this user and you're done and It's not a certificate. It's a simple hash Okay, that you do a hash see you do hash with some random value that only the server knows and you append the hash to this cookie and Send it out again when it comes back, you just check the hash is valid Okay, and you just check the hash is valid on every single request as long as not been tampered with you know that The user hasn't attempted to become somebody else this works great until Something else happens and something else didn't happen back in 2011 so Do you guys remember this who remembers what this is How many people in I've used this thing you guys used it fire shape Yeah, so what does it do? It hijacked session over the air because on Wi-Fi you can decrypt other people's traffic if they're not using WPA to They this network is on WPA to if you're using web is very easy to crack and pull traffic out of the air If you're using an open network, which is basically what you're using in a cyber cafe Any place that has an open network that gives you a browser based login prompt is insecure because every piece of data going on the network Can be sniffed by anybody on the network and what fire ship did was it would essentially sniff traffic off the air and capture login cookies and You can take a cookie from anybody session put it in your browser, and you're not that user Damn simple, you know and this essentially shamed a lot of companies including Twitter and Facebook Into starting to use SSL Until then nobody took SSL very seriously It was considered as something required only when you log in only when the password is being transmitted And you would stop using SSL after the password and say that once you just have a cookie set with the hash You don't need password. You don't need SSL anymore now fire sheep Demonstrated that that was just not good enough. You have to use HTTPS all the time or you're not safe so HTTPS solves most of your problems It does not solve one problem, which is still somewhat critical and that is to do with how you log out again And that's when you need database back sessions now to understand this problem we're talking about essentially a Multi-site login process we're talking about a piece of software that is meant to have one user account That you share across multiple websites in this case the PyCon website, maybe the Hasgeek website Maybe some other website whoever is happening to use this People tend to think of logging in and logging out as what they do with the computer Not what they do with the website Yeah, that you're done with this computer. Please log out. That's how you think about this You know, you don't tend to think of saying I want to log out of every single site that I remember using in the last Whatever period of time so unfortunately cookies on a per-site basis so There were typical logout process you delete a cookie That's what you do when you log out with a cryptographically signed token You simply say the user has hit the logout button so delete the cookie and you're done now You don't know who this guy is anymore You can't do that if they're not on this site right now and when you're doing federated authentication They are not on the site when you hit log out because they hit log out on one side But you want to log them out from five different sites So some services if you remember yahoo in the old days And Google for a while is when you hit log out and look at your address bar It takes you through a tour of websites It'll go to one website after another delete a cookie then redirect you to the next website And if one website happens to be down Your login process has failed. I mean your log out has failed and which is ridiculous. I mean log out failed That is essentially not a nice problem to have and so The way you solve this is by starting to use database back sessions now I got this idea from the GitHub guys get up posted about this on their blog about a year ago and Essentially said that they have switched over to using database sessions. It gives you a bunch of interesting Outcomes now cookies If they got stolen somehow it may not have been over the air anymore because you are using HTTPS But it could be an excess attack a cross-site scripting attack Which you can protect from if you use HTTP only cookies But some of us like to do fancy stuff in JavaScript and therefore you can't use HTTP only cookies and therefore Your cookie is still vulnerable to being stolen from the browser itself How do you deal with the fact that a user may want to say I Want to see where else I'm logged in from and I want to knock off a session which I don't remember Being correct anymore, you know, like I don't remember being in a different country when I'm using this website because I certainly now traveled in the last month So who's the other guy talking off? So if you want to do that then what you do is you start recording your login session as a database entry and Say that this is a session entry in my database Which has the last access time and it has unique session ID and the session ID is one hour to put in the cookie So cookie contains a session ID and it's signed and that's all it has it doesn't have username or anything else Every time a request comes in from the browser you look for the session entry which has this ID and find the user from that and This way you get multiple advantages You can see where else you're logged in from you can see what IP address and browser was used for that particular login You can also log out remotely And when you're logging out from multiple websites, this is a much clearer way of logging out than by doing it in the browser So in the browser you simply say log out once you invalidate that particular row in the table On the server side and you're instantly logged out from everywhere else because that cookie on other browsers is on other websites Invalid now it's going to be discarded the next time the person comes back to the website. So And this gives you a nice stat for the guys who have to do the marketing for your company Usually they want to know how many monthly active users you have if you simply use cryptographically signed Cookies you have no way of knowing when this guy came in last If you use database sessions, you simply look at how many of these sessions were active in the last month and that's it That's your users So you can tell exactly how many users are valid in our active in the last day in the last month last week Whatever you feel like just look in the table so this mostly is what I had to do to Get to the point of saying how do you implement a Permanent session safely In a way that does not cause problems for the user when they discover later on that they were logged into site That they did not intend to be a remain logged into Okay, so I've gotten this far There is The next problem Now this is something I don't have a solution for and this is basically why you should not trust anybody who says They are going to be and your identity provider whether it's Facebook or Google or Twitter At some point in your application You're going to have a point where you want to confirm the user really wants to do something that they just try to do Like they try to delete their own email address from the profile Now that's possible because either they left the company and that address no longer works or somebody's trying to hijack the Recount right now Which one is it? Now you verify we're saying please give me a password to confirm you really want to do something like this if you used Twitter to log in What password now you're going to say okay go back to Twitter and come back and say it's really you and of course Twitter will send you back because that's what Twitter does You know because Twitter says here you already authenticate to this website. I don't need to prompt you again So please go back to the website. So the pseudo problem is the point where you say there is no option but to have a password and That's basically the end of your social logins Okay, unfortunately, but true and the last one is Not quite related to this login business, but it comes in again and now this one is Something that I've been working on in last user Remember we talked about GitHub and the way it deals with you and your organization by saying you have an organization account separate from your account What happens is this does not work in real life I Have created the ability to I've added the ability to create organizations. Let me see if I can just open the page and show you if our connection works So What I've done here is basically defined a bunch of organizations I just type the URL so it's faster in Last user you can do this you can define an organization and then define teams in the organization. This is exactly the same way that GitHub works Now this I've tried putting this into practice in real life and trying to build apps based around this concept It turns out it doesn't quite work because the way this assumes things work is Somebody is the admin who defined this organization in this app and decided that these people belong in this organization In real life, you will not acquire users that way Take the job board The people who go to has job and post a job are not there because Somebody is decreed that you shall use has job. That's not the way it works They just found a site in today's school. Let's go use it and a lot of times You have people who say that I represent this organization and you can verify it because my email address is the same domain and I have we happen to be hiring. He has a JD Now when you do this the person who posted a job is not the owner of the company Is not the authorized representative when it comes to saying I will own the account for this company on this service They simply used it and so you have a bottom-up approach that people come in and give you data in and a bottom-up approach Simply doesn't work when you have to do things like this So I don't have an answer to this one. This is the part I'm working on right now And basically by the time we do Python 2015 I'm going to come back and say hey completely new architecture. There's a new way to solve this problem so This is basically it Things that have learned in the last three years of trying to do user management the right way. It turns out there is no such thing There's always a new wrong way to do it So anyone has any questions. I think we have mostly done for time. We got about five minutes for Q&A Hi, I have a question You said you finally chose the database back sessions Yes, but you still have the log out failed problem there to write because only once only the website you currently on should log out That's it. Okay So because it does that you'll knock it off in the database and from there the cookies invalid now for everywhere else So you don't have to actually delete the cookie because it'll be deleted the next time they come to the website. Yes No matter what it is you're building today, please please please use HTTPS and do it right HTTPS is very very easy to screw up on but fortunately it is not a application developers problem. It's a society's problem So basically it's somebody else's problem not yours Yes, so yeah educate yourself It's the only way I mean it's I thought I knew everything about making HTTPS certificates And then I went to a new website that says let's find new ways in which to discover if your certificate is insecure And it says yes yours is insecure Like I thought I had covered every single base I ran through every single SSL test that somebody had come up with and this one says you're using SSA one instead of SSG 256 as of last month that is considered insecure Like okay, man. I can only do my certificate once a year, you know So anyone else hi Kiran. Yeah So what are the disadvantages of using a database back sessions? The just database rights It seems pretty obvious to go ahead with that solution Yeah, the only one that I can think of as a possible problem is that you're now doing a database right on every single get request Okay, and that's unavoidable you have to write because you need to update the last use timestamp The so I don't bother changing cookies anymore now, you know only when I think there's a serious problem I go change the So secret key, but that's it So earlier if you had a password breach, I mean or if you had a cookie breach The only way to fix the problem for your user is a change in the secret key We change it which locks out everybody on your account. Okay, so with database sessions is easy. Just knock off one row. Yes Yeah Yes, so it is it is it's just equal alchemy Exactly so this is just equal alchemy and The way I approach this problem is to say let's deal with it when there's a problem and so far. I don't have a right problem Okay, so it opens those if you feel like you want to push it to read is please put in a patch Because we already use it is for caching in other parts Hey, Kiran one question. So you said that the if you use HTTP PC card. Yes on you know Yes, yes, and you're not really targeting for the so you're more Fine if you're dealing with users who know what they're what they're up to No, no, see I'm saying that you're if you're giving out as an authenticated service mainly for developers like as a Yeah, out if you're giving. Yeah, is there any problem with just using HTTP. Yes, and Basic out there isn't it's as long as it is not a user who gets confused. It's fine It'll work perfectly fine and in fact within last user. That's how an app talks to last user That okay a client application, you know the website, which is getting a user account has to talk to last user to get details And all of that is using HTTP basic out. Okay, and that's perfectly fine. If it's over SSL In fact the OAuth spec requires it to be HTTP basic out Okay, have you done guys? So I guess we also are out of time. So if you have any more questions, I'm going to be outside and around You can come and talk to me anytime. Thanks you. Thanks everyone