I've looked through the documentation and did a bunch of searching. These are the things I know I can do with a signed url created with CloudFront:
Set a time limit using a canned policy
Monitor how many times the item was viewed
Can I also set a hit limit for my signed URL?
As per your use case you need a one time use URL using cloud front unfortunately using cloud front you can create signed URLs but you can tweak the expiry time of that URL not make it for one time use.
There is another way using cloud front to create a one time use url by implementing AWS Web Application Firewall where you can allow each IP address to access that URL just once by setting the WAF rules.
Related
We are using a GCP environment to setup our project. In that we require the use of dispatch.yaml file.
We want to redirect to the different server URL without changing the domain name in the browser. Dispatch.yaml fulfills this need but it allows only 20 routing rules.
How can we overcome this limitation of Dispatch.yaml? As we require more than 20 routing rules.
Per this Google Groups discussion it seems like this limit is a hard limit unlikely to change, GCP support said that:
With more dispatch rules comes more CPU and memory resource requirements per app. [...].
Ideally it is recommended to design your application to abide by App Engine quotas as they are set to protect the overall underlying architecture. Treating other micro-services as backend services and directly routing requests to them using their full target address via your main frontend default service is the recommended approach. This way you only have to maintain the URL requests to your main frontend client-facing default service, and not every service.
It seems like the request of a quota increase was denied for the user in the Group's discussion and they figured out a solution using Google Cloud Endpoints and the direct module/service addressing scheme in GAE.
The discussion is relatively old, but I believe that they won't change the limit. Nevertheless I would recommend contacting the GCP support and explain your current situation so they can recommend the proper way for your app to avoid the limit.
There's also the possibility of a feature request to increase the limit. There's already one created for this, you can reply in the post stating that you would also like the limit increased, so the GCP engineers know that more users are being affected by the limit.
This is more of a general question about. I have a website running as an Azure App Service. I configured a custom domain so that you are able to call it by my-site-name.com.
As the request of customers kept growing and each customer has specific demands, I was wondering if it is possible to have a subdomain for each customer. For example, client1.my-site-name.com and client2.my-site-name.com.
Is it possible to do all of this within a single App Service or do I need to set up an Azure App Service for each subdomain?
The reason behind my question is, that it would be quite expensive to have an App Service for each individual customer.
You should also consider just adding a wildcard custom domain entry. This is an older blog post, but it outlines Azure WebApp support for Wildcards:
https://azure.microsoft.com/en-us/blog/azure-websites-and-wildcard-domains/
This would mean that *.my-site-name.com traffic goes to your single Web App. Then it is up to the logic of your webapp to determine which client it is by inspecting the hostname of the request (client1.my-site.name.com) and taking the appropriate action to customize the response to that client.
Using a wildcard eliminates the need to add a specific custom subdomain mapping for each client.
It should be possible. Within your app service, if you go to the settings for that service, there is a Custom domains option, select it.
Within there you can then map your subdomains to this service, and it allows you to do it multiple times. You just need to validate and set it up with the A record or CNAME and own the domain. Additionally, you should be able to add SSL Bindings for each.
Here are some documentation on it, I don't believe this documentation handles your exact use case but it does touch on the custom domain portion and should provide additional support.
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain
https://blogs.msdn.microsoft.com/waws/2014/10/01/mapping-a-custom-subdomain-to-an-azure-website/
Let me know if you need more
This seems more like a domain management issue than an azure specific issue. You have already decided to have different sub domains to each customer. That, by definition, means each sub domain needs individual server space. That in turn would mean, an app service for each customer.
So, the answer is what you already have. Have an app service (essentially web server) for each customer via sub domain.
In your position, I would consider some alternatives.
Rebuild your app to work with some form of login system, so clients login and get themselves a separate view.
Alternatively, go with sub folders instead of custom domains. something like, domain.com/client1, domain.com/client2 and so on.
I have a Node.js app that serves http requests. Users can signup, create an account and when they do, I generate a subdomain for them to use. eg username.example.com. This is fairly straight forward to do and can be served over ssl using a single certificate.
I would like to give the option for the user to use their own domain. From Node.js this isn't too difficult either. I can check the hostname and look up the account details from there.
I'm struggling to work out how to generate ssl's for these custom domains though.
Right now, my app runs on Heroku, but I also have a staging build on Google's App Engine, so I don't deal with the web server directly. In fact, I don't even know what it is, it could be Nginx or Apache.
To keep the conversation focused, let's stay I want to stick to app engine. When a user adds their own domain, I store it in the database. How would I auto generate an SSL for this?
I thought of general steps for this, but there is one showstopper which I'm not sure it is possible to workaround. The steps will be:
Map the user's domain to your application and configure the DNS records. You can do that with the gcloud commands: steps and general description outlined in this Mapping Custom Domains docs page (notice that you can switch between Console and GCloud in the boxes). There is also a possibility of doing that within the Cloud Console, however as you've mentioned you're interested in the programmatic approach. If you prefer to configure the custom domain from the API, the same functionality exists in App Engine Admin API with its REST resource for domain mappings.
Possible showstopper (source: Mapping Custom Domains) :
Verify that you are the owner of your domain through Webmaster Central
After that, App Engine provisions a managed certificate and then handles renewing/revoking it. Securing Custom Domains with SSL is still in beta, but it offers the functionality that you need.
I have researched around a bit where all of the captive portals are little bit complicated in terms of configuration.
I dont need AAA , I would just show a webpage where user will be click yes accept terms and then it will redirected.
I am using ignite cloud controller to manage the access points.
Implementing a service where I would like fetch SSID from a repository to match incoming SSID and then redirect based on the SSID.
I am trying to build something externally. My networking skills are pretty new.
I am confused how to get IPAddress and Necessary details from the access point there is an option in ignite cloud controller where I can specify the external settings for captive portal. (Like If my captive portal is running on remote IP, I know I can capture request incoming from access point. How? Can I build a normal web service to do that?)
I think it is straightforward implementation but little guidance is required.
I solved the above by creating a simple web service which filters the request sent from the ACCESS POINT.
There was an option in ignite cloud where I could redirect to my web-service
Once AP redirect I have to set variables in the request forwarding it back to AP with res=success.
Then it will allow me to browse web as expected.
Thanks
when adding a custom domain to Azure app service, the system always trying to validate your custom domain, but this is very annoying for my case.
i have a CDN service which i have put my www. sub domain on it, and the now i am going to move my website to azure app service
actually i have the website up running already on app service, and the only thing i need to do is point the origin server address to app service in CDN setting
but, i need to set up a custom domain on app service for www. otherwise it won't load.
so the worst thing is, when i try to add the www record as custom domain, it validates if the record is really pointed to app service, which is definitely not possible because if i switch the domain really to app service,
first, i can not guarantee all user will get the dns change in same
time
second, then i need to switch www back to CDN after the
validation, then during this period, my app will work without cdn,
which will be a problem also
so is there anyway to add a custom domain without validation.
this is really stupid, i have to say
maybe i am stupid
found the way in office MS documents
here is the link
https://learn.microsoft.com/en-us/azure/app-service-web/app-service-custom-domain-name-migrate
you can set up a txt verification recond to pass the verification