I'm developing a SPA with html5 routes.
Ex: https://app.example.com/restaurants/<restaurantId>/menu etc
Basically the app creates dynamic websites for multiple restaurants, hosted at https://app.example.com/restaurants/<restaurantId>
The requirement is to allow the restaurant owners to host the site in their own domain name.
Ex: if the restaurantId of Example Pizza Shop is xxx
then www.examplepizza.com should serve the contents of https://app.example.com/restaurants/xxx along with all the sub-routes.
The project is hosted on firebase, I'm looking for ideas on how to achieve this (even if I have to use services outside firebase it's okay)
Thanks in advance.
Firebase Hosting is not well-suited to these kinds of multi-tenant use cases, and you'll find the same is true for most "platform-as-a-service" style hosting providers.
To host arbitrary custom domains, you'll need:
Dedicated IP addresses that customers can point their DNS providers to (A records).
A web server capable of dynamically changing what it serves based on the Host header of the incoming request.
An automated SSL certificate provisioning system to create certificates for each customer's custom domain.
This is generally a major undertaking and requires quite a bit of both general and specialized knowledge. I don't think Stack Overflow is going to be the right place to find a specific solution, but I hope this guides you on your journey.
Related
I want to give my customers an option to put their website (HTML, CSS, PHP (optional) ) in a custom domain.
By default, customers will get a basic subdomain like: their-site.mydomain.com
If they upgraded to Pro, I wanted to give an option to use custom domain by adding A record or CNAME.
After some google research, I found that lot of companies are using Amazon AWS for this task. However after checking different article, I did not get any idea how this would work with amazon or any other server.
All stuff needs to be done from the my Application UI by customers. There should be atleast 100s or 1000s of domains. I wanted to redirect each of them to their own website.
Any Idea how this will work? Please add all details if possible.
If I want a multi-tenant environment where customers can create subdomains, what are the pros and cons of creating those subdomains under myexample.com if my main company domain is example.com?
I noticed that Shopify uses myshopify.com under which their create subdomains for their customers.
Coupled with the fact that this is better for security,, it certainly appears that there's a pattern and good reason why companies do this.
Here are some examples:
Shopify
Uses shopify.com for marketing and myshopify.com for subdomain.
Basecamp
Uses basecamphq.com for marketing and basecamp.com for subdomains.
Intercom Articles
Uses intercom.com for marketing and intercom.help for subdomains.
Harvest
Uses getharvest.com for marketing and harvestapp.com for subdomains.
Status.io
Uses statuspage.io for marketing and statuspagestaging.com for subdomains.
Also this article points out the issue with untrusted content (as is the case with Shopify:
Although cookie domains do help to limit the scope of your cookies, it
is still best to avoid having untrusted hosts under your domain. This
is why GitHub pages are hosted under github.io, not github.com, for
example.
I suspect the web domain name prefixed by 'my' is purly emotional rather than technical. It's in the back-end that the domains need to be different, as a resource for enforcing security. There needs to be at least a production and an internal domain. A full suite might be Dev, DevQA, UAT, production and internal domains, with a limited number of people being able to transfer code and/or data across domains.
I have a general question about what Akamai can provide for web services. We are looking to develop a web service and our web service application is hosted in the US, but we would expect that our web service can be accessed from across the globe. I would like to know if 1) Akamai caches dynamic content like web services, and 2) can Akamai provide some better performance if it can cache a web service.
Such as a .ASMX endpoint where there is nothing static about it. The content is 100% dynamic as it fetches data from the back-end like a database and returns it. I’m wondering if Akamai would apply here.
Akamai can definitely be used for web services, it all comes down to your own decisions about how long content should be valid before the server (your service) needs to supply a new version of the content. In simple terms Akamai are only doing what http will do for you anyway, if you set cache control headers for the resources you serve from your API then clients will look at those headers and not request new copies of resources if you've told them that the resource is valid for 10s/10m/10h, etc.
Of course in practice Akamai does a lot more than that, firstly they have over 200k servers globally so your content will sit close to your users wherever they are in the world meaning if that content is still fresh your users will get it very quickly (from a server near them, not from your servers). Secondly, if they do need to request content from you, they do it over a super-optimised network which monitors itself to ensure the quickest route across the globe is taken. If you're concerned about them serving stale content you can even have every request go to your service to check if there's a more up to date copy, eg by using eTags.
The whole thing is highly configurable as well as being extensible from your end using custom headers to instruct their network how you want to deal with different content and endpoints. This is just a quick overview, they can do a lot more as well, definitely worth a look.
Our client has a public site on sitecore, and they are asking us to create their intranet site using Sitecore.
The public and the intranet site sites have different content, but there is a possibility that both of the sites share the same content author users.
What is the best practices to achieve this? using a new instance of sitecore or the same instance.
Any thoughts?
The latest project where I used Sitecore as an intranet platform definitely had a use case for being a separate instance. While it would have been ideal to share license (as #Gatogordo points out) the organization had very strict security policies concerning network connectivity between the Intranet and internal systems.
If your intranet will have any integrations to internal network systems, you should consider the organization's security policies for a situation where a DMZ server (such as a Sitecore instance serving up a public website) is able to connect to these internal systems (such as a Sharepoint instance).
If there are no concerns on that front, HTTPS + Login requirement + disabling anonymous access via Sitecore security across the entire site should be enough. At its core, an Intranet is often just a website that people view after being logged in, and there may be some content you'll want to share between the sites or even content from the media library.
One final concern is your deployment and maintenance schedule. If you are operating the same Sitecore instances for both Intranet and Internet that means you should understand that you will likely have only one VS solution for both. Deploying a fix for the internet is also potentially affecting your intranet. This isn't a bad thing, but I have seen situations where a client did not want systems impacting each other from a deployment perspective. You can mitigate some downtime issues by using load-balanced CD nodes and also ensuring you have solid regression testing in place.
I would use the same instance: it saves you money (license) and you can share the same users for content editing. They don't need new logins and can edit both sites in the same environment.
For the front, you can easily set security on your new site to enable it as intranet. Just make sure you are running in https - best practice would be to do this for both sites.
I work for a company that develops a software product that processes bank transactions and gives the user insight into his/her spending. Our customers (usually banks) integrate the product into their online banks.
I have a question about securing the communication between the online bank, and our system. Before I ask the question, I want to give you some background.
The bank will usually install our system on a set of servers in their hosting environment.
We offer a number of ways to integrate:
Web services - In this case the bank will make calls to a set of REST services on the server, and then generate a webpage with the results (on the server side).
Iframes - In this case the bank will embed iframes in their online bank webpages. The iframes contain webpages rendered directly from our web application.
Inline widgets - In this case the bank will embed JavaScript references on their pages. When the document loads, the JavaScript widgets will render themselves, using AJAX calls. They communicate with a proxy on the bank server, which in turn communicates with our webapp.
We currently have a custom solution where we generate and sign security tokens for the users, and pass these with the requests.
But as banks have very strict security policies, they would feel better with us using a known and trusted security protocol for the communication. It is a big concern, which we want to address.
So the question is, which protocol is best suited for the integration use cases I listed above? There is a plethora of single-sign-on standards out there, and solutions like SAML, oauth, etc. I get the feeling that these solutions might be an overkill for my situation.
I want to find a solution that is simple. As the servers will run side by side in the same hosting environment, and trust each other completely, there is no need for the end user to authorize one or the other (or being redirected between, clicking buttons to give access to the app).
That is, the security protocol should not require any intervention from the end user. The end user simply logs into his/her online bank, and via secure communication has access to the data from our web server.
So...any suggestions?
Thanks a lot!
OGG
After some deliberation, we decided to use 2-legged OAuth (online bank uses consumer key and consumer secret to sign requests to our app).
OAuth signature can either be put in a request header, or request parameters. It nicely solves our problem, as the REST requests can be signed, and the IFRAME src URL-s can also be signed (all communication is over HTTPS).
For those interested, a couple of references:
This article shows using OAuth with IFRAMEs: http://developer.tradeshift.com/blog/cross-site-user-verification/
This article mentiones some security issues with OAuth, and how threats can countered: http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation