Handle custom domain in website builder? - server

I'm trying to build a website builder (that will generate static websites at the beginning).
I don't know how to handle the situation when I need to allow customers to use their own domain.
I did a brainstorm and here is my thought:
Generate their static website (HTML, CSS, JavaScript) into a folder on my
server
When customer enters the domain in my website builder tool => Tell
them to point the domain to my server IP address
Then write a command to automatically generate virtual host/server
block for each of those domains, and point to the location of static
files (HTML, CSS, JavaScript)
I think that kind of approach is quite incorrect somehow.
Can you please tell me what is the approach that website builders like Shopify did this?

Related

Can Squarespace connect to an external Json Rest-API...?

I am new to Squarespace and I was wondering if it can interact with an external Rest-API using JSON?
For example, say I have a Database being hosted privately and I want data from it to be shown via Squarespace and certain pages being restricted according to the user's privileges.
Is any of the above possible, and if so can you direct me to an example? I seem not to be able to find anything on the above via google.
Thanks
From Squarespace:
Squarespace doesn’t support server-side code, including PHP, Ruby, Ruby on Rails, and SQL.
Therefore, the only way to connect to an external API (besides those supported by Squarespace's official 'extensions') is to use "client-side" (in-browser) JavaScript.
So, the database solution which you use must be capable of securely handling client-side connections (for example, Firebase can do that). To interface with it, you must add the JavaScript to your Squarespace site via code block or code injection. An example explanation of doing that can be found at this question.
As to allowing/disallowing content based on data returned from the database, it can be done, but only client-side. That means that, while you can make the site appear to restrict access and/or make it inconvenient for others to access certain pages based on information in the database, because it is all client-side, it could technically be circumvented by someone if they are familiar with web-development, web-inspector, etc. So it's not something you'd want to do if it is critical that the content be truly restricted.
Squarespace does have its own "Members Areas" which can be used to solve content access problems. However, it's extremely limited at the moment, and there are many scenarios it does not address.

Drupal Website to iPhone Webservice API in XML Format

We have our clients website in Drupal at present, for which we needs to create an iPhone App.
So any ideas on how to do that?
Is there any ready made available plug-ins or modules which we can use to generate Category / Articles XMLs directly from database, without much custom code n its headache?
All your suggestions are most welcome..
Thanks !
Yes. You should start with "Services" module, which will allow you to communicate your website with external websites or applications.
Also, you will need a way to communicate with Drupal. We're using XMLRPC, but you can use JSON, Rest...up to you.
Here you have an starting point: http://www.zivtech.com/blog/simplest-drupal-iphone-app
Services implements the most common used methods for Drupal. Which are node saving/load, comments and users. If you need extra functionality, you will need to create a custom module (rather easy).
You can test all the calls with the Services tab in the Drupal website. Just remember to set the permissions.
There is also a Drupal-iOS SDK, which does almost everything I told you, but uses plist instead. https://github.com/seanhellwig/drupal-ios-sdk

Symfony design question - how can I share forms between apps?

I'm developing a site in Symfony, and I'm not sure what the best way is to handle this scenario.
I'm creating a party bookings system. Anyone can go to my frontend app and submit a new booking. Once they're finished, they'll just get a confirmation screen, they can't edit it. Easy.
Only certain users will be able to get to the admin app (it might be secured simply by being on an intranet, but that's not important, just assume it will be only accessible by admin users). They'll be able to view the list of submitted bookings. Easy.
My problem is around code re-use when allowing admin users to edit existing bookings. When you do generate-module in Symfony, the generated module (which as a newbie I'm assuming is a good example of structuring things) creates the form as a partial. I've had to customize this form a lot for my usage (lots of Javascript, etc), so of course I want to re-use this code, to be able to load an existing booking into this form. But there doesn't seem to be a way to share this partial between the apps (I've seen people mention making a plugin...but this seems complicated for this use).
I considered using an IFrame to load the form from the frontend and just passing an "id" parameter to load it in edit mode, but this would mean that the edit mode is not secure - anyone could go to the form on the frontend and pass this parameter to edit a booking.
I also considered putting all of the form display code (HTML, Javascript, etc) in a method on the form object, but this doesn't seem very MVC - all of the display code is then in the form. But this is only because I'm thinking of the form in the same way as a model - is that right?
I feel like this should be a common situation. You can share models and forms between apps, why can't you share this common form display code too?
Thanks!
You should reconsider having 2 applications in the first place. Not only you run into the code reuse problem, but also i18n, testings and other issues. I find it much easier to have 1 application with different bunch of modules for frontend and backend users. You can configure security per module. You can have one sign in form for all users and redirect them to appropriate module based on their credentials.
You can reuse partials between modules inside the same application, but you seem to be talking about two different applications (frontend and backend) so as far as i know the only way is to copy & paste the partial from one application to the other...

fetching a file from a url for mobile app: How to manage server side running Joomla?

Im new to website development and design so apologize in advance if the question is redundant.
I have a program where a client, using a URL string fetches a XML file from a webserver. This would be no problem right if it were a simple URL with no security or no CMS (like Joomla) involved: Just put the exact URL string and the client gets the file from the web server, done.
But, how would the process work if the URL is on my site hosted on GoDaddy and using a Joomla CMS?
Im trying to understand how the same process of fetching a file works on a hosted server using a CMS. Since I just made the transition from my site being on my school's servers to having a Joomla website Im hosting on goDaddy.
I mean where would I put the file if I also want the file to be accessible only if the client authenticates itself first. Just to be on the safe side. I mean is this how normally things work in mobile apps? I have a client program thats a iPhone app and within the app I have a XML file which is used as a data source for my UITavleView, but I want to check some URL to see if an updated version of the XML file exists. My app side programming is mostly done, now Im trying to learn the server side things I need to do to make this process happen with Joomla and my own hosted site
I donot understand how would the process work in that case. I mean, what are the things I would need to do on the server side to and the client side to make this possible?
Please help me understand or if you could point me to some links where these steps are illustrated...or if you could give me some Google key words I can search for to learn about this process.
thanks a lot
The fact that you have a CMS does not generally change how you access a file within the file structure of your domain unless the CMS protects certain directories. In this case, Joomla does not so you can directly access any file you wish. Depending on the sensitivity of the information you are trying to retrieve, you can protect the directory through your domain management panel. If it's not particularly sensitive, the authentication can be done by the app since the URL you are accessing can be easily hidden from the user.
It seems like that would be the simplest solution since the app will have access to user information by nature of where it resides.

Building a webportal which will be rented to customers. Need an Architecture Suggestion

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.