Excuse my lack of server architecture knowledge, but I'm a bit confused on what applications, servers, environments, etc.. are and how they can communicate with each other. I just got AWS and here is what I want to do ultimately.
I want to create a Google Chrome extension. For simplicity, lets say that I'm trying to make an app that records the number of times that all users with the extension collectively visit a given webpage plus information about the visits, such as the time they visited and duration. So if I go to Facebook.com and 100 other people with the extension did, I would see an iframe, lets say, that says "100 users have been here and they visited at these times: ...". Of course, the extension also needs to communicate with the server to increase the count by one. The point is, there is no need to visit any webpage for this app to work since it's an extension and the point isn't to go to a webpage, although it still returns HTML and Javascript.
Now, I also want a homepage for the app in case people are interested in the extension for whatever reason. Just like Adblock, you don't need to go to their actual website, but it's good to have one.
My question is, how do I set this up? Do I just have a normal website, ie. www.example.com/ and set it up normally with Wordpress (what I'd like to use) then just designate one address, ie www.example.com/app, to be answered by my Python app? If so, how do I do that? What do I need in AWS? I'm familiar with Flask and have written apps on my local server using it—can that be integrated with Wordpress?
Sorry if this is confusing.
I also want a homepage for the app in case people are interested in
the extension
The simplest is to host the home page as a static website (Html, css, js) in an S3 bucket.
But if you really want WordPress, you can do that too.
For Backend web services for your plugin to talk to, you can use Elastic Beanstalk, it is a very simple way to do that, without tinkering all the components yourself.
Related
I have a firebase site with a domain of gs-domain1.web.app.
I have a second firebase site with a domain of gs-domain1.web.app.
Now, I want all traffic to go through the gs-domain1.web.app. However, when the path matches a specific route, like, /users/:id/pages, I want the site on gs-domain2.web.app to take over without switching the domain, but maintaining the path.
I believe a redirect will not work because it physically switches the domain.
I believe a rewrite will not work because I can't recreate the path on the destination.
Both the application on domain1 and domain2 are single-page applications (react and vue respectfully).
In firebase, you could host more than one site in one project and that would solve your problem.
Host/Deploy the react code to firebase and link the site with the URL of gs-domain2.web.app
and
do another hosting in the same project as the react but vue on gs-domain2.web.app
After you have successfully linked the domain and hosted the sites... Link the URL together with or anyone you like.
PROS: Your sites would load separately and would be faster.
Also,
It would be great if you put all the code under one domain
Then you can use different paths for the 2 sites so they would be easily identifiable.
so you have : gs-domain1.web.app/path1 and gs-domain1.web.app/path2
You will find the add another site function at the bottom of the hosting section below 1
I am not sure exactly what you mean by "take over without switching the domain, but maintaining the path". If you mean that you want the user to now see the page on gs-domain1.web.app when at this specific path, but still have gs-domain1.web.app as the domain in the url in their browser, I can only really think of two good ways to do this.
You use an iFrame to display the page from gs-domain2.web.app as the entire contents of the page on gs-domain1.web.app at the specific path. This can potentially introduce weirdness if the second page is complex.
You get rid of the second domain and instead move that codebase over to the first domain and write some middleware that serves from the first codebase whenever the user is requesting a path that should come from gs-domain1.web.app currently and serves from the second codebase whenever a user requests a path that should currently be coming from gs-domain2.web.app. I feel that this would be the more 'correct' approach if this is the desired behavior you want.
Alternatively, if you do not care what domain the user is seeing, I would suggest, as you mentioned, merely setting up some clever redirects to bounce users between the two based on which path they are requesting.
I hope this was helpful and goodluck!
So I may have a bit of a strange situation here, and I need some guidance.
The company I work for has a number of small sites, with each site selling a different custom program. The sites are badly in need of an entire rewrite from top to bottom, and my boss has agreed that a login and online purchase/registration is required. This means user accounts, the ability to download a trial from within the user account, the ability to register that trial also from within the user account and the ability to view a list of previous purchases/registrations and product keys.
The thing is, I want a sign-on from one site to be usable on another. Plus, all of this will need to be administered (on our end) from one admin interface. So my thought is that this will all have to be driven by a single database.
Just to be clear: the front-end for each site needs to be different - sometimes only subtly, but in some cases by quite a bit (marketing differences). The backend (both Admin as well as for the Client interface), is identical in structure regardless of the site URL, but the Client interface needs to show different content (programs to download, lists of computers where the program has been registered on, etc.) depending on what URL is being used.
My problem is that I am not entirely sure how to do this from a code-first perspective. The sites are small, quite easy to build on their own, but I want them all within the same Solution so that a change to the model will be reflected across all of them (I will be able to see where things go sideways if the model gets altered - Intellisense is my friend!).
I have looked into Areas, but Areas seem to be a way of partitioning off gross differences within a site (things like resource files - JavaScript, CSS, etc. - remain in the root, whereas in my case each site will need different resource files). I need each section to be its own unique site, with its own unique URL. When this gets pushed to the server, I need each site to be “independent” in that they can sit in entirely different accounts on the same Windows Plesk server (Plesk was not my choice, but the company has clients that need a control panel interface to their own accounts). The only strong commonality between any of them is the database that they will make use of -- in fact, all of them will be making use of the same tables, with very few differences between the sites.
My other problem is that I do not know how to properly implement having multiple projects within a single solution, and all projects making use of the same model that is implemented/constructed only once. I have not yet made the jump to Repository Patterns, so I am completely in the dark with respect to that functionality.
If anyone has a suggestion, I would love to hear about it.
Essentially, you just need to create a class library where you will put your entities and context. If you're using Identity, you'll also put all the Identity-related entity classes here. You'll enable migrations on this class library. The other projects in your solution, then, will have a reference to this class library. You'll need to add the connection string to the individual projects' Web.config files, but other than that, everything will just work.
This is enough to ensure that all the projects are working from a common database and user store. However, in order to actually share authentication, such that signing into one, signs you into all them, you'll have to take one of two paths, depending on how they will be deployed.
If all of the sites will be on the same domain (different subdomains are fine). Then all you need to do is generate a machine key and ensure that each site uses the same machine key in its Web.config. The auth cookie will be added on the wildcard domain, and any subdomain of that domain will be able to see it. Sharing the machine key is to ensure that they can each decrypt it what any one them sets as the auth cookie.
If not all the sites will be on the same domain, then you're in for some pain. You'll have to set up a SSO system, which is non-trivial and far beyond the scope of Stack Overflow to help you with. There's entire companies devoted just to building SSO systems for organizations.
I've currently got a reasonably large site up that i've been asked to make changes to.
Currently To login to this site you need to go to:
www.example.com/folder/loginpage.html
This site is only accessible internally at this time and it is unlikely to ever be accessible externally.
We would like to, however, be able to direct external users to a sub-directory on the site (a 'survey' form) which is located in
www.example.com/folder/subfolder/survey.html
This survey writes its results back to the main application and i believe they are integrated tightly.
We initially tried the idea of using an additional IIS7 box as a reverse proxy however it is quite confusing to me, i'm not very familiar with IIS/ARR and the other features required (i'm mostly familiar with networking). I did try and follow a number of tutorials but didn't get very far. I'd like to avoid it if possible.
How can I, using IIS7 (this site is in ASP.NET) restrict external users from accessing anything other than the survey pages (there are a few included files necessary as well)?
Is it possible to make www.example.com/folder/subfolder/survey.html a 'website' in-itself so that i can publish a URL like survey.example.com externally?
I've come across other examples where access is restricted from specific pages but the root of the site is still accessible
ie
www.eg.com/ is allowed but www.eg.com/admin.aspx is denied. I'd like to the the reverse in effect, and if possible, hide the 'true' url.
Hope someone can help! If using a reverse proxy is possible i'm happy to do it but i'd need detailed instructions.
Thanks for reading,
Much appreciated!
Edit: Sorry all, I'm new to stackoverflow, indeed I've just realised that there are several other sub-communities. Is it more appropriate to ask this in a different community? If so, which one?
Thanks!
I currently develop Drupal web sites using its multi-site feature that allows me to have a single code base and support multiple distinct settings per each site.
I set up a dev server and I was quite happy with my arrangement of domains like example.com.local (not that happy because I had to perform a small conversion before entering production, but still quite happy) and the thing used to work well. Too bad I recently started to work at places outside the LAN in which my dev server resides--mostly at clients' places where I need to demo their sites. First of all I set up a dyndns.org account and the server is accessible through the Internet.
Unfortunately the whole domain-based multi-site ungracefully fell down, since I'm now accessing the server via myservername.dyndns.org and Drupal's algorithm takes the domain name into account, so I'm forced to use at least the TLD as part of the directory name (namely sites/local.example.com). So I decided to switch to directory-based multi-site, and now I'm able to access my server from inside the LAN using myservername.local/example.com (having renamed the sites/ subdirectories accordingly). You should easily see why this is suboptimal, since when I browse to myservername.dyndns.org/example.com Drupal looks for sites/org.example.com. I temporarily ended up making a link from sites/org.example.com to sites/local.example.com but again, this does not scale well If and when I'll have to drop dyndns.org for, say, dev.mycorporatesite.com...
Is there any other possibility? I have full access to the server, I can change Apache2's configs, .htaccess and all the stuff.
I would recommend against referencing drupal multisites in folders but instead would set up your server to have a fixed domain name and each site in a subdomain.
So your dev server is at mydevserver.com
and then each site could be
client1.mydevserver.com
client2.mydevserver.com
etc.
If you also at the same time as creating these, you move the files folder from the default to whatever the live site will be i.e.
sites/livesite.com/files
Then when you have to go live, all the references will be correct (if you are drupal 7 this might not be an issue)
Is it possible or feasible to run a bunch off web sites off of only 1 code base?
For example I have 1 site that bases it's connection string off of the domain name or subdomain name. So, depending on what domain/subdomain is hitting the site the site returns content that is stored in a database specifically for that site.
What types of issues might occur from doing this? Specifically if doing this with asp.net.
It's quite acceptable.
Just note that anyone can change the domain name that you may pick up (as long as you've configured a host header for it), so just make sure you don't go around making something like 'admin.foo' but relying only on that for security (you'd be mad though, obviously).
I see no problem with it.
It works and is proven. Se DotNetNuke for just 1 example of this.
Request come in. Regex/character matchthe domain name. Load settings for that domain (base path to images, css, config, pages etc etc) and off you go.
The gotcha to look out for is if your application is both a) storing data in memory and b) using the same application space. So if, for example, you want to dish up two different blogs and you want the data to be resident in memory (if, say, your back-end store was XML and you didn't want to parse XML with every request) then you'll have to make sure that Asp.Net sees each call as a separate application (which can both point to the same file-system folder and thus uses the same files).
I ran into this exact situation when coding a multi-blog data provider for BlogEngine.Net. It uses a single code base to serve up different blogs based on the requested URL. However, since BlogEngine.Net carries its data in memory, the data provider won't work unless IIS is configured so that each blog is its own application.