Access Azure Blob Files also by Azure Public IPs - azure-blob-storage

I would like to access a blob e.g. https://mystorage.blob.core.windows.net/container/file.dat also by using a public IP from Azure in my embedded application. For example https://1.2.3.4/container/file.dat should be the same file.
I have checked Azure Load Balancer, App Gateway, App Proxy, Azure CDN and Azure Front Door services bud could not find a solution.
EDIT:
Azure storage has private link option. I tried today and no success. Basically I am trying to link my public IP to Azure storage blob access.

This is the error you get:
First, make sure your blob can be access by public:
And if you don't have requirement to set networking, please make sure:
Then set the container access level:
Then, it should be no problem.

Related

How to setup Azure Blob Storage security so that i can be access from webapp

I am creating an Azure Integration SDK which would allow users to interact with azure services via exposed apis. This SDK (jar file created by SpringBoot) could be part of any application with in the organization.
One of the part of this SDK is to expose Blob Storage. I have setup the sdk so far but the testing is done against blob storage which is accessible on public url and being authorized using accountName, key.
Whats the best way to configure blob storage security if
The apps are hosted in azure eco system.
The apps are hosted outside of azure eco system.

Can I make an Azure storage account go offline to test my fallback code?

I am developing an Azure application (C#, .NET 6, ASP.NET Core) that uses Azure blob storage as well as table storage.
I have geo-redundancy enabled on my storage account (RA_GRS) so that if my main storage account goes down, a read-only copy will be available in another Azure region.
When reading from blob storage, as far as I understand, I should be able to get it to automatically fall back to the secondary address by setting the GeoRedundantSecondaryUri property like this:
return new BlobServiceClient(
new Uri($"https://{accountName}.blob.core.windows.net/"),
sharedKeyCredential,
new BlobClientOptions
{
GeoRedundantSecondaryUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/")
});
How can I end-to-end test that I am doing this correctly?
Can I tell the storage account to go offline so that my application should fall back to the read-only backup? I know I can stop an app service using az webapp stop from the command line. Can I do anything similar for storage accounts? Otherwise, how can I test my fallback logic?
(I am asking not only because I want to test the built-in geo-redundancy functionality. I have other failover-related code I want to test.)
EDIT 1: I do not want to use Azure's built-in "initiate account failover" functionality. At least not at this time. I want to test that my application can continue in a kind of "read-only mode" while the primary storage is down.
EDIT 2-3: I have tried to block the primary address ({accountName}.blob.core.windows.net/) using C:\Windows\System32\drivers\etc\hosts. My blob client does not seem to fall back.
If I redirect to IP 0.0.0.0, the blob client throws this: "The requested name is valid, but no data of the requested type was found."
If I redirect to IP 127.0.0.1, the blob client throws this: "No connection could be made because the target machine actively refused it."
If you just want to test the geo-redundancy of your Storage Account, you can initiate an account failover manually from Azure portal & see if your application resumes back the functionality via secondary endpoints.
This documentation might help you out in this scenario: Initiate Azure Storage Account Failover
Note that there will be a certain minimal amount of data loss if you perform a failover, so I'd recommend you to go through the implications of a failover before performing it.

Azure blob not deletable via CDN

I have created an Azure Akamai CDN with an endpoint connected to a storage account (block blob only). I generated a SAS Token with full permissions and it is used to access to a specific container using the CDN endpoint. The SAS Token gives the delete permission and the blobs are deletable throught storage account address (mystorage.blob.core.windows.net) but not deletable throught CDN endpoint (my-cdn.azureedge.net).
Is there a way to delete a blob via CDN endpoint?
Thanks,
Dan
I found that is a Storage Explorer (or AzCopy) issue. It works by REST API and SDK.

How to access Azure blob storage via Flex Application?

Merged with How to access Azure blob storage via Flex Application?.
I am trying to access Blob Storage on Azure via my flex Application. I am doing this via an HTTP Service by using the url given by Azure Blob Storage. However, my storage has private and restricted access and I can only update the storage by using the key (provided by Azure).
Since my application needs to write to this storage, I somehow need to pass in the key via my HTTPService?
Does anyone have any idea how I can do this?
Regards
Aparna

Accessing local Azure blob storage via a simple REST 'GET'

I am working with Windows Azure and am just using the Blob Storage. I have setup my Blob Storage to run in its own Solution file with a dummy web role. I run it first on my development machine so the Azure Services start. I have configured the service to use the development shared key and account name.
I am running into an issue when I point my web application (in another solution) to the local Blob Storage service. I can upload a file to the Blob Storage and I can see the records in my local database. Therefore, I have entered the correct settings in the web.config. However, I cannot access the file via a simple Get request. I have verified that the container is public.
The URI I am using is:
http://127.0.0.1:10000/{container-name}/{filename}.{extension}
My code works when I use my production Azure Services, so is there something different about the Development Environment that I am missing? Does the local environment allow REST access?
UPDATE: I recently found this MSDN Article that describes the differences between production and development Storage URIs. I also documented my environment here on my blog.
The uri looks to be slightly incorrect, the format for the development storage uri is:
http://<local-machine-address>:<port>/<account-name>/<resource-path>
Given that the account name is always devstoreaccount1 your uri should be:
http://127.0.0.1:10000/devstoreaccount1/{container-name}/{filename}.{extension}
What kind of response or error code are you getting?
If you are using IE- you can install Fiddler or use the built in developer tools in IE8 to help debug a communication problem.
Sure- the development fabric works in REST!

Resources