Iam building a web portal which will be rented to customers on a hosted model (SAAS), where they will be using the entire portal features on their own domains with their own branding.
Now I don't want them to get the files of my web-portal, but still be able to use a custom branded portal.
One solution which someone suggested here was to host the branded version on my server and all it via an Iframe on the customer's domain. However I didn't like the idea very much.
One second approach which I researched and found was to host the portal on a fresh IP in my server and ask the customer to point his domain to that ip.
The webportal will be sold to lot of customers and they all will have separate User Interfaces and brandings, so this is needed.
Please suggest me what do you feel about my approach or if you guys have a better idea in mind please pour in your suggestions.
iFrames are evil.
With that said I would probably go with a subdomain approach. They add a subdomain like webportal.somecompany.com that points to you and have your webserver route them to the correct hosted instance of your application based on subdomain. That way their www.somecompany.com still goes to their website.
We're running a SAAS application that supports branding, and we do it by dynamically serving up CSS. If all of your customers have a unique domain name pointed at your server, you could select your CSS files by domain name: If a customer logs in at "http://portal.customer.com/login", you can have his HTML link to the file "/stylesheets/portal.customer.com.css", and so forth. Alternatively, you can create a subdomain for each of your customers, and point them all at your master server, using very similar code to pick the CSS.
This lets you have a single IP address for all customers (and only as many servers as you need to support all your customers behind that IP address), instead of one IP address / server per customer - should cut save on hosting costs!
(NOTE: I'm leaning toward the subdomain approach, the more I think about it. If you're using HTTPS, it would let you use a single "*.yourdomain.com" certificate, rather than trying to mess with separate certificates for each client domain.)
You don't need to run different IPs for different customers. HTTP 1.1 supports Host: like so
GET / HTTP/1.1
Host: example.com
This is how most shared hosts work. When a customer sets up their DNS records to point at your server/load balancer, the incoming requests will have your client's hostname in the headers. Whether you set up virtual hosts in say Apache or do it at the application level is up to you.
Please for your own sake don't do iframes. There's a lot of information on the web on architecture for multi tenant applications.
I made the experience that in such a scenario your customers will come up with any possible web UI requirement you can imagine. Therefore it is rather difficult to build a web UI framework that can accomodate to all the needs, in fact this would rather be a content management system.
Furthemore, for building the web UI, you may meet any combination of customer in-house development, 3rd party web agency or request to get it developed by yourself.
In such situations I made good experiences with offering the SaaS as actual web services allowing custom developed portals to run on top. With this, anybody can build the actual portal with the clients look and feel. You could offer development and hosting as an option.
Related
I know this has been asked a few times, but there seems to be no clear answer ... am searching on this for the past 3 days or more.
There seem to be 2 ways to connect to an Oracle database from an iOS App :
ODBC Client
I need to compile ODBC (which ODBC?) using gcj for ARM. I think this is the hard way, wrought with errors, but possible with quite an effort.
USING WEB SERVICE
Connect from App to webservice and from web service to Oracle DB.
Are these the 2 methods available or any other?
Few questions on the two methods:
a. Which is more secure?
b. Will my company's security department oppose to any of the above?
c. Which is more performant?
d. Which of the above does one normally use?
Webservices are the answer, you do not want people connecting directly to the database from a mobile device. A Webserver will add one extra layer of security as well as the ability to handle simultaneous request without stressing the database directly
a. Which is more secure?
Webservices as explained above
b. Will my company's security department oppose to any of the above?
Yes, security department will insist not to open the oracle port to connect directly, unless they have it already open.
c. Which is more performant?
Webservices, setting up the right cache policies in a webserver can save resources to the database.
d. Which of the above does one normally use?
Webservices, because they offer you great advantages in security and performance, not only that, webservices are reusable and can be accessed by many different platforms, think on the future you might want to serve your application later on Android devices and Webservices will save you a lot of development time.
Many of today's top applications in the market use webservices, think about it.
Google Maps is a great example of how powerful webservices are!
It's not a good idea to connect to your database directly from your app. It can be secure if you create an account that can do nothing but SELECT, but there are some other things to consider.
Why burden the app with the Oracle client?
If you have many users you have to worry about Oracle handling a huge number of simultaneous connections. With a Restful API requests are stateless.
If you decide to change your schema. You'll also have to change your app. When you place a service in between, the app is no longer dependent on the schema.
ODBC connection will require that the Oracle port is open to the Internet, which in vast majority of cases will not be allowed for security and performance reasons. Even if it were, or even if you establish a secure VPN, a direct database access requires that the connection is kept open, which can be problematic when a mobile device can go in and out of the network coverage.
HTTP is far more tolerant to unreliable networks and can be encrypted using SSL (HTTPS). The problem with HTTP is that database do not have direct support for this transport so most people develop dedicated web services.
I work on a project called SlashDB, which automatically constructs RESTful APIs out of databases. For public APIs you would install /db in so called DMZ (a network segment between two firewalls) as described in this blog post.
SlashDB can be configured to allow restricted data access to public users or you can define specific users with varying privileges to data. It is designed as stateless service, which means that you can easily set up multiple nodes behind a load balancer and reverse HTTP proxy for high availability web scale deployments.
Regardless whether you develop the web service by hand or use our product you will achieve better scalablity, performance and security for your solution than by using direct client/server approach. I would even argue that REST APIs should be used internal enterprise data integration solutions but that's a whole new topic.
I am going to repeat what everyone else said, Rest API is the way to go. Do not connect to the database directly. However, there might be a way to connect to your database which I never tried my self.
http://odbcrouter.com/iosvsweb#hn_iOS_Open_Database_Connectivity_SDK
I've been following instructions on the Azure site to add a CNAME to point to my Azure website. I have had some problems getting it to work and there seems to be some contradictory information in some of the posts.
I have my website running in "Shared" mode, which according to the Azure instructions supports custom domains and indeed it seems to allow me to manage domains. But some posts seem to indicate that I have to run in reserved mode. Can anyone confirm this?
Also, some posts seem to indicate that I need to add the CNAME in the Azure management portal, but I cannot find where this is. Any help appreciated?
I don't really understand A records and CNAME that well. My DNS provider allows me to add both. Do I need to change both? Currently my A record points the "root" to the IP address that Azure gives me and the CNAME points www.mydomain to the Azure website host mysite.azurewebsites.net. I have left them for a while to propogate and nothing seem to happen.
The notion of FREE, SHARED, RESERVED website categories are very recent; Microsoft Launched it just 2 days ago. Earlier it used to be either FREE or RESERVED. You get to attach a custom domain name only for reserved instance.
With the new feature of low cost shared option, you get to attach a custom domain but it will still be in the shared pool of Azure Websites. It works out around $9.36 a month.
The reason for contradiction info in the posts are due to new to features. In short you can use both SHARED and RESERVED for attaching custom domain. With shared it is little cheaper provided you are fine with your website being served for shared pool.
Just go the SCALE Table and make your website instance SHARED from default free and then go to Configure table to put your CNAME
DNS Management is handled differently by different domain or hosting providers , there are three places these changes can be performed (may be more )
cpanel
domain manage panel
WHM panel
if you have only taken a domain most probably your domain provider will send you a url, in which "manage dns " option will be there.
if your site is already hosted then you might have to do it in cpanel or whm.
so better call your domain hosting provider for exact steps . it saves a lot of time
I'm working for the first time on a MS Dynamics CRM 4.0 project. Our company has a high number of remote employees and even more remote consultants. As such it will be necessary to make the CRM solution available over the internet. As near as I can tell, I have three options:
Have everyone use a VPN to access an intranet site (typical onsite deployment). However, we have found that VPNs are far from trouble free and cause many support issues. We avoid them like the plague.
Use IFD to expose the CRM on the internet. I don't know much about this except that the URL will be different than the onsite URL, which could cause some headaches (see below).
Expose the CRM site by opening the site to the internet, using SSL to encrypt traffic. We currently do this with our MS sharepoint sites. I'm not sure how secure this would be (one of the reasons for this question).
I'd like to avoid using both the onsite intranet deployment and the IFD together for a couple of reasons. One of the requests for the solution is use email to notify users that they've been assigned a task, and include the URL to the task within the email. For this reason. If both deployments are used, then I'll need to include two URLs and the user would need to know which to use. Which leads to the second reason, the main users of the solution split time between being in the office and being remote. Thus they would need to access the solution two different ways, and know when to use which. Bad.
So, what are the advantages/disadvantages of any of these methods? Any other options? Is there any issue using IFD from within the intranet? Security issues?
UPDATE:
Be sure to read the comments of the accepted answer, as they further explore the ramifications of the various options.
That is the best, you have all the security, and a low maintenance deployment. Also if you are developing custom code (ASPx pages) you will have only one deployment type to support. If your users are already using a VPN Client, this should be the best solution.
This is the Microsoft way to do it. Except for the URL duplication. This solution is used in companies where clients do not want to have a VPN client, or where VPN clients can't pass thru firewalls. Also this solution is almost required if your outlook clients are using "Connect to exchange thru the web". Because in this case all the clients can open Outlook without VPN, CRM should be exposed without VPN, and the IFD deployment is handled natively by the Outlook client. Note that this is SSL enabled (required). EDIT : It's not required, but a best practice, even if the implementation guide says "You must define a URL for the Microsoft Dynamics CRM IFD by using the following format: https://".
This this the worst of all the worlds, you have to maintain the deployment manually, and you will have all the headache of using a deployment as we were using it in CRM 3.0 (NTLM, Kerberos etc). I do not recommend this.
You can use an IFD deployment thru the intranet, but there is some buggy behavior. The external DSN should be configured on the internal DNS server, so that internal client can access the internal server. And because IFD is SSL enabled, you are encrypting internal traffic...
Hope this help!
I need a webbased group chat client that can interact with various xmpp servers.
I did some research and found muckl , speeqe and tigase minichat but I have one more issue I am deploying my site on shared hosting.
So want to know if anybody has installed any group chat software on shared hosting ( like bluehost ) and which will be the best possible client for the same.
Speeqe is actually 99% javascript, so it will work well on shared hosting. The requirement for Django is just to do things like remember sessions and have nice url structure. It may take a small amount of work to take away Django, but it shouldn't be much.
There are also Django hosting providers, so that might be an option.
Speeqe can also work with any XMPP server, public or self-hosted, etc. I used it many times to join groupchat rooms on arbitrary servers, and there is even an IRC gateway.
For XMPP shared hosting, there are several options now, including a service by Process One: http://process-one.net
Prefer responses via php or ROR if possible!
Example:
The slide widget at www.slide.com can
be deployed anywhere on the web. But
the slide developers have
centralized edit capabilities to these
widgets. A change to the widget core,
will update across all installed
widgets.
Can this be done with an entire website engine?
Say I coded the Wordpress
engine. Is it possible for me to
deploy my engine on my customers own
servers at their own domain while
still being able to
control/update/edit the core and have
it update all my clients engines.
The main reason is for clients to have ownership of their content and brand. A customer may need to establish his online presence and so he needs his own domain, but he still can pay a service to have his engine professionally managed and upkept.
As far as I can tell the flash objects in the slide.com widgets are hosted on their servers, all that is deployed elsewhere is markup that references the widget similar to embedding a YouTube video. Unless there's something there that I don't see.
There are 2 ways you could do what I think you're asking.
1) You could provide a service that hosts the web application on your servers. The user could point their domain to your server and you would run the application under a virtual host and give them administrator access to the application to brand it. Essentially you would be providing a web hosting service with the application engine pre-installed.
2) You could allow them to deploy it on their servers and provide automatic updates that would download and replace the application files when they are changed in the core. However this would require script write access to every folder where scripts are stored, so it would pose security problems on their server.
Depending on the type of application you could also have much of it deployed as services on your servers, and some type of basic wrapper that is deployed on the customers servers that communicates with your services. You could then centralize all of the business logic and have images and templates and such stored on their servers, and possibly scripts that communicate with their database.