Another reason github went with github.io for pages is reduced possibility of XSS and reading github (.com) session data from user-controlled content on github pages (github.io).
Best, David Allison Co-Founder & Chief Technology Officer, Nulu, Inc. www.nulu.com On Aug 26, 2013, at 12:02 PM, James Miller <[email protected]> wrote: > Hi Hillary, > > Subdomains can be a good fit for certain apps, but can also add an unneeded > layer of complexity to apps that don't need it. > > One "pro" is that since URLs are already scoped to a subdomain, uniqueness > checks on usernames can also be scoped to the subdomain. Example: > Freshbooks.com - our account usernames are "james", "josh", etc. - names that > are certainly reused by other subdomains. It gives you the impression that > you're the only one using the system since you never get the "username is > already taken" message. > > A few cons: > - You have to give away subdomains (duh). Some apps resort to a totally > separate domain than the primary domain -- GitHub pages uses *.github.io. If > you forget to blacklist certain subdomains in your app, people can create > "mail.yourdomain.com" or "www.yourdomain.com". > - SSL is more expensive. Not prohibitively for low-end certs, but definitely > worth consideration. It is not possible to get wildcard "Extended Validation" > certificates if that's a requirement. > - Additional SQL query (or maybe just a join) necessary on every request to > find the subdomain -- this isn't necessarily too painful, but again, > something to consider. > > I'd say if you don't have a good reason for the additional subdomain scoping, > don't bother. > > James > > > On Sun, Aug 25, 2013 at 5:09 PM, Ben Wanicur <[email protected]> wrote: > Hi Hillary > > I'm not sure if there is much impact on the back end. If you are building a > Rails site, there are some nice tools available to help you route and deal > with subdomains. > > First, you can route certain requests that contain subdomains using > constraints in your routing: > http://guides.rubyonrails.org/routing.html#advanced-constraints > > Also, you can grab the subdomain using request.subdomain and use that in your > controller for finding users/organizations, etc... > > I think the advantage with this approach is cleaner URLs, perhaps SEO > advantages for your users/organizations (?), and if you are customizing the > look/feel of a user/organization's page, it's nice for them to have a unique > URL. > > I've done this before on projects, and Rails really makes it a breeze. You > have to be sure that you register a wildcard domain so that *.yourdomain.com > gets sent to your app. > > Cheers > > Ben W > > > On Sun, Aug 25, 2013 at 4:43 PM, Hillary Hueter <[email protected]> wrote: > I'm creating a web app for a travel companies to manage tours. So it's a SaaS > application. It seems to be the trendy thing for applications where the focus > is on the organization (e.g. Lighthouse, Harvest, Beanstalk Source Control) > for them to have a custom subdomain like http://company_name.someapp.com. Is > there an advantage from a backend perspective for doing it this way, instead > of just one login/url entry? I noticed that Basecamp doesn't handle things > that way and they have a pretty large customer base. > > > > -- > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google Groups "SD > Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google Groups "SD > Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google Groups "SD > Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
<<inline: nulu-RGB-100w.png>>
