Can I find out what domain made a request that triggered an HttpModule? - dns

How do I find out from within an HttpModule what domain made a particular request?
Say I only want to allow site1.com and site2.com to use images from my server, how do I check that it is them making the request?

There's no way to do this in every case. Consider that UrlReferrer may not be set. Also, consider that you could be called by a client that does not have a DNS address.
Instead, you should consider configuring IIS to authenticate using user certificates. If you've only got a small number of sites calling you, generate a certificate, register it with IIS and map to the user you want, then give the certificates to those two machines to be installed on them.

Request.UrlReferrer, but it can easily be spoofed.

Related

best way to redirect securely one domain to another in IIS without having a website

I would like to know what is the best way to redirect everything from marketing-address.com to real-address.com.
best means
as less effort as possible,
as cheap as possible,
as secure as possible.
In detail:
Less effort: If possible without the need of creating a website oder some code like javascript
Secure: https://marketing-address.com should be accpeted by the browsers - no warning.
Cheap: if possible without buying a certificate (I don't think that this is possible) and without having a second webserver running
So in theory, the communication would be like this:
Making the address targeting the same IP address
Making the existing IIS listen to that address to
Let IIS tell the caller "yes, you're totally right here, but I neither I have a website nor do I have a certificate, but you don't need anything of that since you get redirected anyway..."
Is there a chance to accomplish that? If no, I would need to buy a certificate. What would be the solution then?
There are 2 restrictions:
We are using an Azure App Service for hosting an asp.net core site, which seems to be very restricted in configuration possibilities
The browser should definetly show the real-address.com in the URL, not the marketing-address.com.
Have you tried to use an Application Gateway before the IIS/Webapp at the backend?
I believe the AppGW will solve these issues, the AppGW can redirect the hostname to another web address, as many you want to.
https://learn.microsoft.com/en-us/azure/application-gateway/ssl-overview#tls-termination

Is it possible to use the same node.js server for two/three different domains (aliases)?

Is it possible to use the same nodeJS server for two/three different domains (aliases)? (I don't want to redirect my users. I want them to see the exact URL they typed in the address bar. However, all three domains are exactly the same!)
I want my users to be logged in on all three domains at the same time, in order to avoid any confusion.
What is the simplest way to do this and avoid cross-domain issues?
Thanks!
If you mean that all domains will serve the same nodejs app then Yes you can do that.
but if each domain should open a different application then you must have a reverse proxy running on the server to handle and manage the sites/vhosts.
You may install nginx and use it as reverse proxy server or look for http-proxy a library for nodejs.
If you would like to manage the vhosts in your app you can look for vhost middleware for nodejs and use it
Choose one of:
Use some other server (like nginx) as a reverse proxy.
Use node-http-proxy as a reverse proxy.
Use the vhost middleware if each domain can be served from the same Connect/Express codebase and node.js instance.
This is a very broad question. Moreover, it is generally a pretty bad idea, SEO-wise, to have multiple independent domains that each serve the same content.
Logging in is generally either done through Cookies, or through extra parameters in the URL. Cookies are always domain-specific, for obvious security reasons. If you want to ensure folks will be logged in to all the domains at once, you can create an internal purpose-driven domain to handle authentication (without such domain showing in URL bar, and only being used for HTTP redirects, effectively); such domain will store the login state for all the rest, and the rest would pick up the login state through such purpose-driven domain (through HTTP redirects).
In general, however, this sounds like too much trouble. Consider that, perhaps, some users specifically want to use different domains for different accounts, so, you'll effectively break their usage if you mandate that a single login be used for all of them. And, back to the original point, doing this is pretty bad for SEO, so, just don't do it.

Are there alternatives to validate the domain for mailgun?

We want to use the mailgun api (in a parse project) and tried to verify our domain.
We are supposed to change the DNS-Record of
mailo. _domainkey.
But our hoster (strato) tells us that this is not possible at all. It's one of the biggest hoster in Germany!
Is there another way to verify our domain? We just want to send emails and don't want to receive them through mailgun.
You should consider switching registrars (or at least DNS providers). This is called a "TXT" record, and it is considered a standard feature of DNS.

Custom Domains for a Simple Web App

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.

SaaS DNS Records Design

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.

Resources