Subdomains + Development = Sucks: A quick tip from Kevin Hale of Wufoo(particletree.com)
particletree.com
Subdomains + Development = Sucks: A quick tip from Kevin Hale of Wufoo
http://particletree.com/notebook/subdomains-development-sucks/
22 comments
I agree... I think this idea of ownership is growing as "everyday" web users feel a need to own their online identities and data. We already are seeing this with tools like Weebly. Web developers and techies have enjoyed this luxury for quite some time.
One thing I really like about subdomains is that it makes accessing a site very quick... from my address bar I type "new" and news.yc.com pops right up!
One thing I really like about subdomains is that it makes accessing a site very quick... from my address bar I type "new" and news.yc.com pops right up!
Not so much suck as have two sides of a coin. Ok, so the article says you may need to buy an SSL certificate for the domain and setup user1.localhost.localdomain in dev machines.
On the positive side, your users will be cleanly sandboxed in separate domains, they get slash-free URIs, and you can have simple IP-based load balancing.
Any good stories about subdomains? Infogami?
On the positive side, your users will be cleanly sandboxed in separate domains, they get slash-free URIs, and you can have simple IP-based load balancing.
Any good stories about subdomains? Infogami?
One benefit of subdomains is that you can set cookies for each subdomain separately. For example, I can be logged in to my user1.example.com and user2.example.com both at the same time without having to logout and then login again.
I haven't implemented mass user-generated subdomains in PHP or Python, but it certainly was a snap to do in Rails.
User-created subdomains didn't seem like they really caught on until 37 Signals started having huge success.
User-created subdomains didn't seem like they really caught on until 37 Signals started having huge success.
Question: does the choice to use subdomains or subdirectories affect the stats that appear on traffic measuring sites like Alexa?
It affects some of the measuring sites, and web crawler speeds etc. Now Alexa implicitly says it doesn't affect their stats, but it would be nice to know something about their algorithm for distinguishing "recognized personal pages": http://www.alexa.com/site/help/?index=12 (edit: corrected the link to point to traffic rankings faq)
thanks for the note kevin!
What I hate is that firefox/IE complain if you don't get one of these paid SSL certificates. The encryption of HTTP traffic should be free and without unneeded burden.
https and SSL are free. It's just that if the certificate is not from a recognised authority it warns you. That's a good thing in my book.
That's terrible in my book. What if you are running an entertainment site with lots of subdomains and for every single subdomain the user gets harassed with this question?
These certificates have nothing at all to do with "authority." Just think about it, what exactly do they prove?
Why should you only be allowed to speak in confidence with well identified parties (not that verisign remotely attempts to identify anyone)? Think carefully.
Related: http://www.schneier.com/blog/archives/2005/12/new_phishing_tr.html
These certificates have nothing at all to do with "authority." Just think about it, what exactly do they prove?
Why should you only be allowed to speak in confidence with well identified parties (not that verisign remotely attempts to identify anyone)? Think carefully.
Related: http://www.schneier.com/blog/archives/2005/12/new_phishing_tr.html
The SSL software in your web browser uses the information from the certificate authority to mathematically PROVE a man in the middle attack is NOT happening.
Anytime you use a self-signed certificate [edit] without manually verifying the fingerprint of certificate [/edit] ANYONE who controls the network hardware between you and the second party can eavesdrop and even tamper with the communication stream. Neither you nor the second party has any way of knowing what's going on. That's why we NEED a warning every time we encounter a self-signed certificate.
The default behavior of the browsers is fine and we're lucky that the design allows us to fool around with self-signed certificates at all.
EDIT: If you manually verify the fingerprint of the self-signed certificate each time you connect you can be sure your connection is secure. But still the UI makes sense (even more sense).
Anytime you use a self-signed certificate [edit] without manually verifying the fingerprint of certificate [/edit] ANYONE who controls the network hardware between you and the second party can eavesdrop and even tamper with the communication stream. Neither you nor the second party has any way of knowing what's going on. That's why we NEED a warning every time we encounter a self-signed certificate.
The default behavior of the browsers is fine and we're lucky that the design allows us to fool around with self-signed certificates at all.
EDIT: If you manually verify the fingerprint of the self-signed certificate each time you connect you can be sure your connection is secure. But still the UI makes sense (even more sense).
"""Anytime you use a self-signed certificate ANYONE who controls the network hardware between you and the second party can eavesdrop and even tamper with the communication stream. Neither you nor the second party has any way of knowing what's going on. That's why we NEED a warning every time we encounter a self-signed certificate."""
I believe that you misunderstand the technology.
I believe that you misunderstand the technology.
I'm by no means an expert on crypto but I think I understand the fundamentals. If something I said is incorrect please point it out specifically. See [1] for a more complete explanation of my point.
[1] http://en.wikipedia.org/wiki/MITM
[1] http://en.wikipedia.org/wiki/MITM
Doesn't the browser warn you by default for self-signed certificates? If so your second paragraph is incorrect isn't? You would get a warning every time you encounter a self signed certificate.
The language in my post is a bit sloppy and for for that I apologize. As I imply in the second paragraph and explain in the edit you do get a warning BUT unless you then pull out your paper copy of the fingerprint and manually compare the fingerprint of the certificate with the one you have on file you do not know that your connection is secure. When is the last time anyone took that step? We need CAs to automate this process for us.
The Authority provides a way to check the address of a domain name holder and other useful information. It makes it a lot harder for someone to create a spoof domain like https://www.paypa1.com and for Paypal's real address to be displayed in the certificate when you click on it. Basically Verisign and co stake their reputation on checking the details of the certificate applicant.
I don't see what's terrible about browser makers trusting certain authorities. It's useful to the user, and there's more than one authority so less chance of abuse. The only alternative is no authorities, or a government bureaucracy issuing them. I don't see how either of those 2 options is superior to the current situation.
There's nothing stopping you creating a free Certification Authority, it's just that you'd have to persuade the browser makers to trust you.
I don't see what's terrible about browser makers trusting certain authorities. It's useful to the user, and there's more than one authority so less chance of abuse. The only alternative is no authorities, or a government bureaucracy issuing them. I don't see how either of those 2 options is superior to the current situation.
There's nothing stopping you creating a free Certification Authority, it's just that you'd have to persuade the browser makers to trust you.
"""I don't see what's terrible about browser makers trusting certain authorities"""
Because the authorities trust anyone who pays them 20 bucks. THEN, the users trust any site where the address bar turns yellow. Do you see the break in the chain here?
Because the authorities trust anyone who pays them 20 bucks. THEN, the users trust any site where the address bar turns yellow. Do you see the break in the chain here?
You're changing your argument, Your initial point was that encrypted HTTP should be free. It is.
Then you switched to say that you can't really trust Authorities. Maybe so, but the current setup seems better to me than the alternatives.
Then you switched to say that you can't really trust Authorities. Maybe so, but the current setup seems better to me than the alternatives.
Read Schneier's take on it that I linked to. He agrees that this false sense of positive identification can be WORSE than none at all. And that has to do with the warnings that the browser gives, not the matching up of the domain names.
Second, my argument has always been that the browser should not harass the user of a site that has not taken part in this PHONY identification procedure.
Heck, even google adsense has seen through this scam and not bothered to pay the fee.
Edit: To clarify, most users equivocate signed SSL certificate == trustable site. That is WRONG. Verisign does not vigorously establish the non-evilness of your site.
Example: http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html
Second, my argument has always been that the browser should not harass the user of a site that has not taken part in this PHONY identification procedure.
Heck, even google adsense has seen through this scam and not bothered to pay the fee.
Edit: To clarify, most users equivocate signed SSL certificate == trustable site. That is WRONG. Verisign does not vigorously establish the non-evilness of your site.
Example: http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html
Alternatively, maybe most users don't pay attention to URLs or look at the distinction above in the same way we developers do.
Also, the subdomain strategy seems to have worked well for Blogger. They serve users' pages from *.blogspot.com, and their own pages from *.blogger.com.