I am the programmer behind IvyLees The network for PR and business
and Presskit'n Do-It-Yourself Public Relations.
I developed the sites with django and also administrate the servers.
I am one of the developers in Match Strike: we build websites.
greg_allard: RT @IvyLees Interview with John, the mysterious creator of ‘E-mails from an Asshole’ http://bit.ly/f1DxK
greg_allard: lots of good presentations at #cdwsbarcamp today
I’ve been working on a project for a while and it has recently started to expand to an additional domain name. The domains will be using the same user base and I want to make it simple for users to be logged in at both applications. With a little research I dug up a few options I could go with. There is a redirect option, a javascript option, or a single sign on option.
With the redirect option I could redirect users to the main domain, check for cookies, and redirect them back so that they could get new cookies for the additional domain. The downside to this method is it will increase traffic for every pageload from a new visitor even if they will never need to log in. And since the sites this was for will have pages being viewed many more times than there will be logged in users, it wasn’t worth all of the extra traffic. It might be possible to minimize this traffic by only redirecting on login pages, but if the login form is at the top of all pages then it doesn’t help much.
Facebook uses a javascript method on all of the sites where you see facebook connect so you can use your facebook credentials to comment on blogs and other things. This method may be fine for their case, but again it will cause the extra traffic since the javascript is still connecting to the main server to get cookie info. I also don’t want to rely on javascript for my sessions.
I wanted a solution where it would only keep users logged in when they needed to be kept logged in. One way of knowing if they need to be kept logged in is: they are on one domain and click a link to go over to the other domain. Using a single-sign-on link to the other domain, the user would stay logged in at the new domain. The only use case that this doesn’t account for is someone is logged in at one domain and then types the other domain into the address bar. However that is a minimal case and I think the sso link will be the best way to keep users logged in most of the time and keep the overhead down.
I plan on open sourcing the django sso code so that other people can use it in their projects. It will allow a django site to accept single sign on requests and it will also help to create single sign on links to other sites. Both ends of the process don’t need to be a django site since it should work with other applications that use this type of process to authenticate users.
I’ll write a post on here about how to use the code once I get it set up at google code so if you are interested in that, you should probably
subscribe to the rss so you don’t miss it.
Related posts:
I just went through the whole xbox live cancel thing too. No place on the site or in the console to quit. Tech support e-mail would always say call them. The person on the phone was able to take care of everything and even mentioned billing.microsoft.com would allow you to stop the auto renew. I didn’t try that out since I was already on the phone. I don’t know why the e-mail support responses left that out. If that site works for someone, it would be nice to know.
greg_allard: Youth Action Project Cleans Up Seccombe Lake Park http://ivylees.com/3vEdY
This wiki was created to list what tools are used by which startups. http://startuptools.pbworks.com/
greg_allard: New PR tool Presskit’n revolutionizes public relations approach http://ivylees.com/HtrsI
greg_allard: when using related_name=”stuff” in django models, foreign_object.stuff only works if the app is listed in installed_apps in the settings
