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]<javascript:>
> > 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]<javascript:>
>> > 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] <javascript:>
>>> 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] <javascript:>.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  -- 
>> -- 
>> SD Ruby mailing list
>> [email protected] <javascript:>
>> 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] <javascript:>.
>> 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.

Reply via email to