No, you can get a domain that cover all subdomains (*.mydomain.com). It is called wildcard certs.
https://www.geocerts.com/ssl/wildcard They cost a bit more ( i think about 5-10 times more, IRRC.), but if you are using a bunch of subdomains if is worh it. One caveat is that the domain cert only cover one level deep. so if you have mail.*.mydomain.com, that one won't be in the cert. On Thu, Aug 29, 2013 at 10:53 PM, Hillary Hueter <[email protected]>wrote: > so I would have to get a cert for each subdomain? > > > On Monday, August 26, 2013 12:02:56 PM UTC-7, James Miller 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<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 <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<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 sdruby+un...@**googlegroups.com. >>>> >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>> >>> -- >>> -- >>> SD Ruby mailing list >>> [email protected] >>> >>> http://groups.google.com/**group/sdruby<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 sdruby+un...@**googlegroups.com. >>> >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<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.
