Just for clarification, EV certs are not more secure from an encryption perspective, they just give the visitor more visibility of who owns the certificate. You could say this is more secure because it may reduce the success of phishing attacks, but it still relies on people being aware enough to know that they should have received the EV indicator and didn't.
On Thu, Aug 29, 2013 at 8:18 PM, John Lynch <[email protected]> wrote: > Hillary, you can get an old skool wildcard SSL cert that works for all > subdomains, but like James said you can't get a new type of cert which is > supposed to be more secure. > > > http://www.networksolutions.com/support/why-can-t-i-get-a-wildcard-extended-validation-ev-ssl-certificate/ > > - John > > > On Thursday, August 29, 2013, Hillary Hueter 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. > -- -- 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.
