I want to give my customer the ability to create their own todos list app/web.
So, I thought they could register to my application, for instance:
http://mytodos-app.com/signup and provide all preferences such as theme, title, name...
Now i could use the url/router ability to get some unique identifier from the url and use the same app, but fetch data for each customer.
i.e: http://mytodos-app.com/todos/:someuniqeid
1) is it sounds ok? or are there better strategies for this scenario?
2) if it's ok, If I want to give them the ability to configure their own domain (like in shopify you get some dynamic domain yourname.shopify.com).
So, what is the most popular/professional way to do it? I want it to be easy to the customer. any suggestions?
Other than the "cool factor", there is no benefit to using actual customized sub-domains.
You can synthesize the behavior by:
In DNS, set up a wildcard CNAME entry for *.DOMAIN.com to point to www.DOMAIN.com, be sure to buy a matching wildcard ssl/tls certificate.
Configure the web server to respond to all hostnames.
After user registration. SANITIZE the username(or whatever identifier) value.
Set an authorization cookie with the domain=DOMAIN.com option to force it not to
be a host cookie.
Redirect to username.DOMAIN.com. Same server different name.
Check the cookie in the route to serve the correct pages. Just like
you would with any login.
If there is no cookie, use the host information to populate the
username portion of the login page, or display public todos?
Make sure any Javascript scripts hosted on the site and all internal links are loaded by relative addressing.
The technique is much safer than actually creating real subdomains.
Related
I have set up a secondary domain on my BC hosting successfully and have already set it up to point to a homepage and the url stays the way I wish, for example www.[secondary domain].com
I now want to setup a web app to use my secondary domain rather than my default, does anyone know how I would achieve this?
Fore example at present it looks like this www.[default domain].com/[webapp name]/ I would really want it to read www.[secondary domain].com/[webapp name]
I am going to have to use redirects when promoting the page and just accept that the proper url is going to be www.[default domain].com/[webapp name]/
BC serves all content the same, no matter which domain it is accessed from.
Proper server-side 301 redirects are unavailable, since BC gives us no method to discriminate by domain. You can perform a client-side 'redirect' though, after comparing the hostname in Javascript (with something like document.location.host).
There is also Liquid Markup, which you can use to detect the domain and vary the served content accordingly.
You'll need to ensure all links to the app are fully qualified, including the preferred domain.
I'd also add canonical links (<link rel="canonical" href="...">) to each page of the app. This will indicate the preferred domain to search engines.
Note the inverse is also a problem; content on your primary domain will also be accessible through the secondary domain, causing rank dilution / duplicate content issues.
I've created a really simple databaseless php application that I want to offer as a hosted solution. I've enable wildcard subdomains so that users can sign up and create a subdomain (e.g. "user.myapp.com"). However, I would like to offer the ability for my users to use a custom domain as well if they prefer. I'm pretty sure this can be accomplished by asking the user to add an A Record to their custom domain pointing to my server's IP, but I'm not sure how to handle the domain on my end once they create an A Record pointing to my server's IP.
So, say a user signs up for my service under "user.myapp.com" and then they decide they want to use a custom domain "someuser.com" instead. My specific question is — once the user adds an A Record to their domain "someuser.com" pointing to my server's IP, how do I tell my server to point that domain to "user.myapp.com"? Or is there an easier way to do this?
You'd need to first setup your server to accept requests from someuser.com, which is entirely different than setting up a wildcard for your server alias (e.g. *.myapp.com). You can have a default vhost handle all the hostnames that no other vhost is setup to handle, but then you're still left with mapping someuser.com to user.myapp.com.
Depending on how you've setup your php application, the user's going to need to enter the custom domain they've registered that they had point to your app, then you'll need to know to do that mapping internally by checking the $_SERVER['HTTP_HOST'] server variable to see what host the request is for, and if it's for someuser.com, then map it to user.myapp.com.
I've read lots about what can be done with mod_rewrite but I haven't found one to solve my problem. Maybe it can't be done?
I have a sub-domain on my primary domain that I have a customer direct user to to use one of my programs. The customer doesn't want his customers to see that that are on my domain and he doesn't want to use an iframe.
So, is it possible for the user to only see www.subdomain/program.php instead of www.subdomain.mydomain.com/program.php?
If you want the browser to show www.subdomain/program.php in its location bar, you need to register the www.subdomain domain name. There is no way to remove bits of the domain name using anything in the htaccess file. For example, if you've registered example.com and you have a server at foo.example.com, and you want to be able to go to http://foo/some/path/index.html, you're out of luck because the browser is going to attempt to do a DNS lookup of foo and it will most likely fail unless there happens to be a "foo" server under the DNS search domain. Browsers put a great deal of effort to prevent spoofing of the domain name, since it would be really bad if I was able to spoof my website to show the domain of a bank in a browser's location bar while actually visiting an entirely different website.
Background context: ASP.NET / IIS (not sure if it matters)
I have a web app at example.com, and a user of my app gets his own content page at an address like example.com/abc-trinkets. I would like to offer the user the ability to point his own registered domain at my web app so his content is accessed at abctrinkets.com. Initially looking on the order of 10-100 users with custom domains.
Ideally, I would like my user to just have a single hostname or IP address that he needs to know to configure properly with his registrar, and if I change the setup of my servers (different host, change addresses, load balancing, etc.) the user will not have to change his settings.
I have no trouble handling the requests once they hit my web app, but I am looking for input on the best way to set the routing up so requests actually come to my app/server. I would like a "catch-all" type of behavior that does not require me to individually configure anything for each domain a user might point to me.
I assume I will need some kind of layer between the address I give my user and my actual server ... is this like a managed DNS service or some other type of nameserver thing I would set up with my host? Is this something simple that should already be handled by a few simple settings on my webserver? I worry that I am making this more complicated than it needs to be.
Write a script that examines the Host header in the request. In your example, if it's abctrinkets.com, then you'd either redirect or forward the request to /abc-trinkets. You'd still need a database or something for mapping the domain names to the URLs; if you're going to allow arbitrary domain names for each user account, then there's no possible way to avoid that.
This question is an extension to previously answered question
How to give cname forward support to saas software
Sample sites -
client1.mysite.com
client2.mysite.com
...
clientN.mysite.com
Create affinity by say client[1-10].mysite.com to be forwarded to europe.mysite.com => IP address.
Another criteria is it should have little recourse to proxy, firewall and network changes. In essence the solution I am attempting is a Data Dependent Routing (based on URL, Login Information etc.).
However they all mean I have a token based authentication system to authenticate and then redirect the user to a new URL. I am afraid that can be a single point of failure and will need a seperate site from my core app to do such routing. Also its quite some refactoring to existing code. Another concenr is the solution also may not be entirely transparent to the end user as it will be a HTTP Redirect 301.
Keeping in mind that application can be served from Load Balanced Web Servers (IIS) with LB Switch and other Network appliances, I would greatly appreciate if someone can simplify and educate me how this should be designed.
Another resource I have been looking up is -
http://en.wikipedia.org/wiki/DNAME#DNAME_record
You could stick routing information into a cookie, so that the various intermediary systems can then detect that cookie and redirect the user accordingly without there being a single point of failure.
If the user forges a cookie of his own, he might get redirected to a server where he does not belong, but that server would then check whether the cookie is indeed valid, and prevent unauthorized access.