I have created an API using AWS Lambda functions. I need to give access for the API only to a particular domain.
I have tried out replacing my own domain in the formats like example.com, www.example.com, https://www.example.com in the access control allow origin box. But when I hit the API from outside it is accessible.
Does anyone have some solution for the problem mentioned above?
Only my domain name for eg...www.example.com should have access to the api and other domain names like www.exampl-one.com should not have access
you can set access-control-allow-origin to the required domain. When webpage hosted under the domain call the API the preflight call will be performed. if referring domain and access-control-allow-origin cors documentation
Related
I have a domain that is protected through Azure b2c. The way I set it up is that a domain linked through Azure front-door is the login domain.
login.contoso.com
The app domain is
my.contoso.com
What is happening is that when I go to login.contoso.com (without any routing or path redirect uri's) directly it will default to a 404 error and land on this page
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
To note, the correct path works. i.e. login.contoso.com/<token>azureb2c...
The issue is how to I handle the 404 error?
I'd like to default direct that to my main domain site i.e. contoso.com or someotherpage.
The odd part for me is that because the domain, sub-domain, is login.contoso.com I don't think there is actually a page from Azure emitting that. I think, correctly, that is just my domain's way of handling 404's or wrong page.
I already handle the redirect if the person goes to my.contoso.com and isn't logged in they go directly to login.contoso.com However, I don't think i'm handling the 404 errors correctly because anything outside of that emits the previously described error screen.
So I think the question is, how can I direct a subdomain's 404 to a url of my choosing of a domain that is setup through Azure front-door?
Is that just in the same permissions of my webconfig for the main app service domain ie., contoso.com? Or, is it the webconfig of the app service specifically for the subdomain my.contoso.com?
• You can surely configure the redirection for your different subdomains from a particular subdomain URL while logging in or any other kind of activity like session auto-logout after token expiration by configuring the correct routing rules for redirection in the Azure front door classic version.
Kindly check the snapshot below as demonstrated according to your requirement: -
Thus, according to the above snapshots, you can configure the redirection for the ‘login.contoso.com’ URL to the desired domain URL of your choice, i.e., ‘contoso.com’ or ‘someotherpage.com’ for in Azure AD B2C too.
• Also, in the above snapshot, I have selected ‘Temporary Redirect (307)’ for HTTPS protocol as according to the below documentation link, the target resource is temporarily under a different URI. The user agent MUST NOT change the request method if it does an automatic redirection to that URI. Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.
https://learn.microsoft.com/en-us/azure/frontdoor/front-door-url-redirect?pivots=front-door-standard-premium#redirection-types
As you want the redirection to happen for the ‘login.contoso.com’ URL when you redirect to that page, it will surely happen when you configure it accordingly as above since this redirection is temporary according to the situations stated above.
Is there any way to get the IP of the website that made the request to the API?
I am working on an application that allows multiple websites to access the API, while the end user IP doesn't really matter. Using the Origin header is not really helpful since you can mock it in Postman.
Can I safely allow just a few websites to access the API? Using CORS, from what I know it uses the Origin header as well.
Are other workarounds for this?
I want to only allow users from my own IP and two domains which would cover the client's intranet and external secure website. Should I be doing it in web.config? Azure itself?
Thanks for the help :-)
The mechanism to control which referral domains are allowed to access resources in your Azure Web App, or any other HTTP endpoint for that matter, is called Cross-Origin Resource Sharing (CORS).
CORS is an IETF standard (RFC6454) and is supported and configurable for any Web App / App Service. However, it will not help you in what you are trying to achieve.
Web browsers nowadays operate what's referred to as same-origin policy. This is where a browser will only fetch resources from the same domain present in the address bar. Why? It's really a security mechanism designed to protect the user against cross-site scripting (CSS) attacks, where a malicious actor may craft scripts to make calls to websites a victim is currently logged in to, where their cookie will automatically be sent to the server to sign in, thus being able to carry out activities as the victim. CORS allows developers to permit cross-origin requests safely by white-listing particular domains which are allowed to access resources.
CORS should not be used a mechanism to restrict access to a site. Neither should the referrer HTTP header be used when locking down access to a website, since this can easily be spoofed. Further, CORS operates on an honorary basis meaning that, should origin be indeterminable, the request will be allowed, as it is assumed that the request is same-origin, or initial.
What you are looking for is IP restrictions. Azure Web Apps support IP restrictions. In the portal, navigate to your Web App -> Networking -> IP Restrictions. This area will allow you to configure IP addresses or ranges that are allowed to access the application. You will need to create a rule allowing your IP address and addresses relating to the "referral domains" in question, which demands that the users are coming from known addresses.
So, to answer your question, it should be done in the portal, and you should use IP restrictions.
How can I build rest API with nodejs and limit user access with whitelisted ip or domain?
so, if domain or ip address not whitelisted, they cant access the API.
anything I need to build that?
If I'm understanding your question correctly, you want to whitelist domains that can make cross-origin requests to your API.
You can use something like NPM's CORS package, which will let you develop a request whitelist and reject calls from unapproved origins.
I am working on web application that has angular 4 on frontend and WEB API on backend. This application is hosted on MS Azure and until now we didn't have any issues.
Currently we need to integrate with one payment provider. During payment user is redirected to his payment page, and if everything goes well user is redirected back to our web site. Beside the browser redirect (which may fail) payment provider supports server to server call (HTTP GET). In this way they make sure we get information about the transaction. The problem here is that instead of one call to our Web API backend we get always two calls. After checking the request origin IP addresses I concluded that there is two origins (one is payment provider address and another is IP located in USA, which I assume belongs to MS). This looks to me like a routing problem, but I am not very experienced at this.
Did anybody have similar problem on Azure while hosting web application ?
According to your decription, it seems that fails for cross domain request. Azure website is supposed to manage CORS for you.
I think you missed a handy Azure website blade: Specify the origins that should be allowed to make cross-origin calls (for example: http://example.com:12345). To allow all, use "*" and remove all other origins from the list. Slashes are not allowed as part of domain or after TLD.
Cross-Origin Resource Sharing (CORS) allows JavaScript code running in a browser on an external host to interact with your backend. Specify the origins that should be allowed to make cross-origin calls (for example: http://example.com:12345). To allow all, use "*" and remove all other origins from the list. Slashes are not allowed as part of domain or after TLD.