So I am creating a web app, that will give each registered user a unique 'workspace'. This workspace should be accessible by anybody they give permission to.
I have the main domain for my marketing website, but I am trying to figure out how to manage the nitty-gritty domain management of the web app itself.
Should I buy generic domains that I then use to allow the users to chose one of them for their workspace, and create a unique subdomain there, or how should I approach this?
My web app is written in Rails.
The term Domain has a few meanings - I assume you mean "Domain" as in the hostname in a Domain Name or URL, also known as the "third-level domain name" (e.g: www.mysite.com - where mysite.com is the hostname).
I am trying to figure out how to
manage the nitty-gritty domain
management of the web app itself
I've usd 4th level domains before (also known as local hostnames, e.g: images.mysite.com, admin.mysite.com), but these were provisied via a helpdesk at the telco who managed the A-Records for our domain name, so it wasn't a quick and easy automated process.
I've also seen hosting firms provide web-based tools that allwo you to do this yourself - where they manage the A-Record.
In both cases management of the 4th level domains is performed manually. I haven't hread of anyone automating this within an app the have developed - it's obviously possible but definately non-trival.
Should I buy generic domains that I
then use to allow the users to chose
one of them for their workspace, and
create a unique subdomain there, or
how should I approach this?
It depends. Even if you host the application there's no reason why the client can't set-up a 4th level domain that points at your server and not their own; this would mean that your app would need to lookout for the 4th level domain only as there's no guaratee they'll be using a 3rd level domain your app "knows about".
Say John Brown from 'Studio ABC' signs
up at mysite.com, what should I do?
Give them studioabc.mysite.com or
mysite.com/studioabc
It depends on what you want to achieve and what over-heads your comfortable with:
The "mysite.com/studioabc" option should be easy to auto-provision through your app, so in some ways that'd be easier to work with.
A problem with the "mysite.com/studioabc" option is that (depending on how much control you have over the web server) all your files (from all clients) will be in the same place - that will make it more complex to manage (back-ups, etc).
The "studioabc.mysite.com" is going to be harder and slower to provision (as DNS changes are required), but you have the advantage in that you can run them as seperate sites if you want to. For example, if "thebeatles.mysite.com" takes off you'd be able to move it to a different physcial web server that had better performance, but you can't move "mysite.com/thebeatles" so easily.
In both cases your app will be a Multi-tenanted one (except in cases such as studioXXX.mysite.com where the site is hosted elsewhere); data access becomes an issue - keeping the clients data separate. There's different approaches you can take for this, see this article on Multi-Tenant Data Architecture. (BTW - I know it's an MS article and you're working in Rails! - but it's an excellent article which will be helpful).
Buying a generic name is, well, generic. If you wanted to foster a community of clients around a particular thing then get a domain name that makes sense for that; if you use your own domain name it would in-effect be a form of advertising.
And rather than it being mysite.com,
should it be obscuredomain.com that
the actual web app resides at and
therefore gives the subdomains of,
because mysite.com is the marketing
site.
I think either will work - the question is what do you think you're clients would prefer? How does that stack up with your business model? The domain name is an important part of any online presence (from a marketing side) as it helps define the identity of the site and those who use it - so choose carefully.
Do you ever want to sell this off? If you do you'd want to build it on a domain name that you were happy to sell with it. So with that in mind I'd have a domain name for your product / service and a seperate one for your business - assuming that you'd one day want to sell the site but not your business. Alternatively, if the website is the business and you're happy to sell them as a whole package then I'd put it all under the same domain name.
Finally, you might have more than one domain, each providing a different level of service (and each could have 4th level domains hanging off it instead of www):
www.mysite.com
www.mysitepremium.com
www.mysitecheapskate.com
Related
Can MODX serve a single site instance to a subscriber-based audience, whereby common elements are served to all users, while each individual subscriber's content is stored uniquely and presented in the front end only to them?
To clarify this scenario, consider a website that provides financial budgeting tools. In this example, a single instance of the website and its components is served to all users, simplifying maintenance, progressive design enhancements, etc., while each user's data (i.e. their financial details) is accessible only to them via log-in credentials.
The default MODX setup does not to support this example. Static elements can be used, but this alone doesn't cover the above scenario. So my question is whether MODX can support the above scenario, and if so, how it can be accomplished? I'm not looking for specific details -- but broadly, what options exist? If there are options, is it even a good choice for this kind of scenario?
MODX does an excellent job with common pages, and the built-in ACL system will allow you to differentiate access for any number of closed participants groups.
As for the user's personal data, there are two possible ways: create some custom code or use an existing one. Each of these paths will almost certainly extend the current user model and use it for your needs.
Here are a couple of useful links regarding your question:
https://docs.modx.com/current/en/extending-modx/custom-users
https://docs.modx.com/3.x/en/extras/login/login.tutorials/using-custom-fields
https://modx.com/extras/package/classextender
I have three different website.
can we run on a single instance in umbracocms.
how can i map three different website in single umbracocms and host on serv
You can, but that doesn't always mean that you should. If you want three different sites, you can have three root nodes, and set the hostname for each of the sites to the domain that you want to use. Once you've done that, just point the three domain names at your IIS website, and you should be good to go.
You'll need to make sure that you set all of the back office permissions properly if you don't want the users to be able to each of the sites. If the sites are all for the same client, and have common design, then hosting in one instance is probably OK. If they're all different and for different clients, it'll be much easier to manage them as separate Umbraco sites, IMHO.
First you need to setup the content tree in your Umbraco backoffice.
Create a home node for each website and setup the correct hostnames.
After that view this wiki page that explains what needs to be done at your server.
https://our.umbraco.org/wiki/how-tos/running-multiple-websites-on-one-umbraco-installation
VS2013 update 4, MVC5
Still relatively new to MVC. To divide functional domains within an MVC project the use of Areas seems clear from these posts (olderSOlink, newerMVC5link).
Is there ever a reason that sub-domains would be integrated as part of a solution involving different functional domains of a given MVC project? I don't have a reason to want to make use of sub-domains, I'm just asking because I don't know if there is some advantage I should know about.
Is it even possible without great difficulty? For example, can logons transfer across sub-domains? Would there be other difficult issues to address?
At present the project I am building is 'relatively' small and will have around 5 major domains so I'm assuming Areas is the best architecture to isolate these domains, but I wanted to ask for guidance before I go too far and make decisions that would make the use of sub-domains difficult in the event there is a compelling reason to use them in a single MVC project.
I generally use subdomains to separate major application functionality or if I have multiple servers that I want to be on the same domain name.
To answer your login question, if you are using the same application you will remain logged in on the whole domain (depending on your method of using sessions, the cookie will be accessible to the domain as a whole).
If you are questioning using subdomains, they are really just a naming scheme so you could categorize your 5 major applications into one domain with different paths (eg. /portal, /store, /etc..) then later you could point store.domain.com -> domain.com/store. So it's pretty flexible in the end.
I would like your guidance on this.
I'm trying to build a website that has two "players" (which, I assume can be translated to "roles"?). One player is "consumer" and the second player is "supplier".
Both are interacting through mutual (sql server) database.
Now I would like to have totally separate systems each player, with totally different authentication mechanisms.
However, I would like to have the consumers system as sub-domain of the main domain, i.e., I would like to have the consumer system under 'mydomain.com', and the suppliers system under 'supplier.mydomain.com'.
However, I can't figure out how to technically do this? Can I create another web project in my solution, call it 'suppliers' and let it include all the features of the suppliers system?
Or should I create separate controllers for the suppliers features inside the main project?
The first option sounds most "clean" to me, however, how can I route the user from the main (the consumers) website to the suppliers website based on the subdomain?
If I choose the second option, how can I make sure that user which authenticated as customer will not be able to perform as supplier?
This is probably very common task to do, any good tutorial or example for this?
You will create two separate IIS applications - one for your consumers and another for your suppliers.
You will then set the host headers on each to your required domain and subdomain. IIS will then take care of routing URLs to your separate applications. Instructions for setting IIS host headers here https://technet.microsoft.com/en-us/library/cc753195.aspx
As for managing application code, given you want complete separation I would suggest creating three Visual Studio projects:
Web application for consumers
Web application for suppliers
Class library of shared code - database logic etc
You are then able to develop and deploy each web application independently.
In terms of tutorials, there is quite a lot available, here are a few which will help you:
https://web.archive.org/web/20211020150710/https://www.4guysfromrolla.com/articles/122403-1.aspx
https://www.simple-talk.com/dotnet/.net-framework/partitioning-your-code-base-through-.net-assemblies-and-visual-studio-projects/
https://softwareengineering.stackexchange.com/questions/207101/managing-multiple-projects-that-share-code-customization
for this problem, so use "Area" =
https://msdn.microsoft.com/pt-br/library/ee671793(v=vs.100).aspx
I want to build a RoR web application in SaaS architecture. Should I have a single database for every clients or multiple databases for each client. And also I wonder that each client should use the own separated application on sub domain or not. Although it depends on business logic but I want to learn how I can choose the correct way and what the best practice is.
Thanks,
There is no correct answer here. The first solution would be to have each client completely independent: their own application space and database.
However, you may want to design a framework which is common to all clients, and just change the branding for each client. The downside of this is the effort you need to keep them separated - for instance cross-contamination and security.