Research
Security News
Quasar RAT Disguised as an npm Package for Detecting Vulnerabilities in Ethereum Smart Contracts
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Azurite is an open-source Azure Storage API compatible server (emulator). It provides a local environment for testing and development of applications that use Azure Storage services, including Blob, Queue, and Table storage.
Blob Storage
This code snippet demonstrates how to start the Azurite Blob service on port 10000. Blob storage is used for storing large amounts of unstructured data such as text or binary data.
const azurite = require('azurite');
azurite().blob().listen(10000, () => {
console.log('Azurite Blob service is running on port 10000');
});
Queue Storage
This code snippet demonstrates how to start the Azurite Queue service on port 10001. Queue storage is used for storing large numbers of messages that can be accessed from anywhere via authenticated calls.
const azurite = require('azurite');
azurite().queue().listen(10001, () => {
console.log('Azurite Queue service is running on port 10001');
});
Table Storage
This code snippet demonstrates how to start the Azurite Table service on port 10002. Table storage is used for storing structured NoSQL data.
const azurite = require('azurite');
azurite().table().listen(10002, () => {
console.log('Azurite Table service is running on port 10002');
});
LocalStack is a fully functional local AWS cloud stack. It provides a local testing environment for AWS services, including S3, DynamoDB, and SQS. Unlike Azurite, which focuses on Azure Storage services, LocalStack emulates a wide range of AWS services.
MinIO is a high-performance, S3-compatible object storage system. It is designed to be used for large-scale data infrastructure. While Azurite emulates Azure Blob storage, MinIO provides an alternative for S3-compatible object storage.
Fake S3 is a lightweight server that emulates the S3 API. It is useful for testing S3 interactions locally. Unlike Azurite, which emulates Azure Storage services, Fake S3 focuses solely on the S3 API.
Note: Azurite V2 has been moved to legacy-master branch. Master branch has been updated with latest Azurite V3. V3 currently only supports Blob and Queue service, please use V2 for Table service for the time being.
Version | Azure Storage API Version | Service Support | Description | Reference Links |
---|---|---|---|---|
3.3.0-preview | 2019-02-02 | Blob Queue | Azurite V3 based on TypeScript & New Architecture | NPM - Docker - Visual Studio Code Extension |
Legacy (v2) | 2016-05-31 | Blob, Queue and Table | Legacy Azurite V2 | NPM |
Azurite is an open source Azure Storage API compatible server (emulator). Based on Node.js, Azurite provides cross platform experiences for customers wanting to try Azure Storage easily in a local environment. Azurite simulates most of the commands supported by Azure Storage with minimal dependencies.
Azurite V2 is manually created with pure JavaScript, popular and active as an open source project. However, Azure Storage APIs are growing and keeping updating, manually keeping Azurite up to date is not efficient and prone to bugs. JavaScript also lacks strong type validation which prevents easy collaboration.
Compared to V2, Azurite V3 implements a new architecture leveraging code generated by a TypeScript Server Code Generator we created. The generator uses the same swagger (modified) used by the new Azure Storage SDKs. This reduces manual effort and more facilitates better code alignment with storage APIs.
3.0.0-preview is the first release version using Azurite's new architecture.
Try with any of following ways to start an Azurite V3 instance.
After cloning source code, execute following commands to install and start Azurite V3.
npm install
npm run build
npm install -g
azurite
In order to run Azurite V3 you need Node.js >= 8.0 installed on your system. Azurite works cross-platform on Windows, Linux, and OS X.
After installation you can install Azurite simply with npm which is the Node.js package management tool included with every Node.js installation.
npm install -g azurite
Simply start it with the following command:
azurite -s -l c:\azurite -d c:\azurite\debug.log
or,
azurite --silent --location c:\azurite --debug c:\azurite\debug.log
This tells Azurite to store all data in a particular directory c:\azurite
. If the -l
option is omitted it will use the current working directory. You can also selectively start different storage services.
For example, to start blob service only:
$ azurite-blob -l path/to/azurite/workspace
Start queue service only:
$ azurite-queue -l path/to/azurite/workspace
Azurite V3 can be installed from Visual Studio Code extension market.
You can quickly start or close Azurite by clicking Azurite status bar item or following commands.
Extension supports following Visual Studio Code commands:
Azurite: Start
Start all Azurite servicesAzurite: Close
Close all Azurite servicesAzurite: Clean
Reset all Azurite services persistency dataAzurite: Start Blob Service
Start blob serviceAzurite: Close Blob Service
Close blob serviceAzurite: Clean Blob Service
Clean blob serviceAzurite: Start Queue Service
Start queue serviceAzurite: Close Queue Service
Close queue serviceAzurite: Clean Queue Service
Clean queue serviceFollowing extension configurations are supported:
azurite.blobHost
Blob service listening endpoint, by default 127.0.0.1azurite.blobPort
Blob service listening port, by default 10000azurite.queueHost
Queue service listening endpoint, by default 127.0.0.1azurite.queuePort
Queue service listening port, by default 10001azurite.location
Workspace location path, by default existing Visual Studio Code opened folderazurite.silent
Silent mode to disable access log in Visual Studio channel, by default falseazurite.debug
Output debug log into Azurite channel, by default falsedocker run -p 10000:10000 -p 10001:10001 mcr.microsoft.com/azure-storage/azurite
-p 10000:10000
will expose blob service's default listening port.
-p 10001:10001
will expose queue service's default listening port.
Or just run blob service:
docker run -p 10000:10000 mcr.microsoft.com/azure-storage/azurite azurite-blob --blobHost 0.0.0.0
docker run -p 10000:10000 -p 10001:10001 -v c:/azurite:/data mcr.microsoft.com/azure-storage/azurite
-v c:/azurite:/data
will use and map host path c:/azurite
as Azurite's workspace location.
docker run -p 8888:8888 -p 9999:9999 -v c:/azurite:/workspace mcr.microsoft.com/azure-storage/azurite azurite -l /workspace -d /workspace/debug.log --blobPort 8888 --blobHost 0.0.0.0 --queuePort 9999 --queueHost 0.0.0.0
Above command will try to start Azurite image with configurations:
-l //workspace
defines folder /workspace
as Azurite's location path inside docker instance, while /workspace
is mapped to c:/azurite
in host environment by -v c:/azurite:/workspace
-d //workspace/debug.log
enables debug log into /workspace/debug.log
inside docker instance. debug.log
will also mapped to c:/azurite/debug.log
in host machine because of docker volume mapping.
--blobPort 8888
makes Azurite blob service listen to port 8888, while -p 8888:8888
redirects requests from host machine's port 8888 to docker instance.
--blobHost 0.0.0.0
defines blob service listening endpoint to accept requests from host machine.
--queuePort 9999
makes Azurite queue service listen to port 9999, while -p 9999:9999
redirects requests from host machine's port 9999 to docker instance.
--queueHost 0.0.0.0
defines queue service listening endpoint to accept requests from host machine.
In above sample, you need to use double first forward slash for location and debug path parameters to avoid a known issue for Git on Windows.
Will support more release channels for Azurite V3 in the future.
Releasing Azurite V3 to NuGet is under investigation.
Integrate Azurite with Visual Studio is under investigation.
Optional. By default, Azurite V3 will listen to 127.0.0.1 as a local server. You can customize the listening address per your requirements.
--blobHost 127.0.0.1
--queueHost 127.0.0.1
--blobHost 0.0.0.0
--queueHost 0.0.0.0
Optional. By default, Azurite V3 will listen to 10000 as blob service port, and 10001 as queue service port. You can customize the listening port per your requirements.
Warning: After using a customized port, you need to update connection string or configurations correspondingly in your Storage Tools or SDKs.
--blobPort 8888
--queuePort 9999
--blobPort 0
--queuePort 0
Note: The port in use is displayed on Azurite startup.
Optional. Azurite V3 needs to persist metadata and binary data to local disk during execution.
You can provide a customized path as the workspace location, or by default, Current process working directory will be used.
-l c:\azurite
--location c:\azurite
Optional. By default Azurite will display access log in console. Disable it by:
-s
--silent
Optional. Debug log includes detailed information on every request and exception stack traces.
Enable it by providing a valid local file path for the debug log destination.
-d path/debug.log
--debug path/debug.log
Azurite V3 supports SharedKey, Account Shared Access Signature (SAS), Service SAS and Public Container Access authentications, you can use any Azure Storage SDKs or tools like Storage Explorer to connect Azurite V3 with any authentication strategy.
An option to bypass authentication is NOT provided in Azurite V3.
Azurite V3 allows customizing storage account names and keys by providing environment variable AZURITE_ACCOUNTS
with format account1:key1[:key2];account2:key1[:key2];...
.
For example, customize one storage account which has only one key:
set AZURITE_ACCOUNTS="account1:key1"
Or customize multi storage accounts and each has 2 keys:
set AZURITE_ACCOUNTS="account1:key1:key2;account2:key1:key2"
Azurite will refresh customized account name and key from environment variable every minute by default. With this feature, we can dynamically rotate account key, or add new storage accounts on the air without restarting Azurite instance.
Note. Default storage account
devstoreaccount1
will be disabled when providing customized storage accounts.
Note. Should update connection string accordingly if using customized account name and key.
Note. Use
export
keyword to set environment variable in Linux like environment,set
in Windows.
By default, Azurite leverages loki as metadata database.
However, loki limits Azurite's scalability and extensibility.
Set environment variable AZURITE_DB=dialect://[username][:password][@]host:port/database
to make Azurite blob service switch to a SQL database based metadata storage, like MySql, SqlServer, MariaDB.
For example, connect to MariaDB, MySql or SqlServer by set environment variables:
set AZURITE_DB=mariadb://root:my-secret-pw@127.0.0.1:3306/azurite_blob
set AZURITE_DB=mysql://localhost:3306/azurite_blob
set AZURITE_DB=mssql://username:password@localhost:1024/azurite_blob
Note. Need to manually create database before starting Azurite instance.
Note. Blob Copy & Page Blob are not supported by SQL based metadata implementation.
Tips. Create database instance quickly with docker, for example
docker run --name mariadb -p 3306:3306 -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mariadb:latest
.
Azurite V3 provides support for a default storage account as General Storage Account V2 and associated features.
devstoreaccount1
Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
Note. Besides SharedKey authentication, Azurite V3 supports account and service SAS authentication. Anonymous access is also available when container is set to allow public access.
As mentioned by above section. Azurite V3 allows customizing storage account names and keys by providing environment variable AZURITE_ACCOUNTS
with format account1:key1[:key2];account2:key1[:key2];...
.
For example, customize one storage account which has only one key:
set AZURITE_ACCOUNTS="account1:key1"
Or customize multi storage accounts and each has 2 keys:
set AZURITE_ACCOUNTS="account1:key1:key2;account2:key1:key2"
Typically you can pass following connection strings to SDKs or tools (like Azure CLI2.0 or Storage Explorer)
The full connection string is:
DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;
Take blob service only, the full connection string is:
DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;
Or if the SDK or tools support following short connection string:
UseDevelopmentStorage=true;
Connect to Azurite by click "Add Account" icon, then select "Attach to a local emulator" and click "Connect".
Because Azurite runs as a local instance for persistent data storage, there are differences in functionality between Azurite and an Azure storage account in the cloud.
Please reach to us or open issues if you need multi storage account support.
Azurite V3 supports a default account as General Storage Account V2 and provides features.
devstoreaccount1
Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
The service endpoints for Azurite are different from those of an Azure storage account. The difference is because the local computer does not perform domain name resolution, requiring Azurite endpoints to be local addresses.
When you address a resource in an Azure storage account, use the following scheme. The account name is part of the URI host name, and the resource being addressed is part of the URI path:
<http|https>://<account-name>.<service-name>.core.windows.net/<resource-path>
For example, the following URI is a valid address for a blob in an Azure storage account:
https://myaccount.blob.core.windows.net/mycontainer/myblob.txt
However, because the local computer does not perform domain name resolution, the account name is part of the URI path instead of the host name. Use the following URI format for a resource in Azurite:
http://<local-machine-address>:<port>/<account-name>/<resource-path>
For example, the following address might be used for accessing a blob in Azurite:
http://127.0.0.1:10000/myaccount/mycontainer/myblob.txt
The service endpoints for Azurite blob service:
http://127.0.0.1:10000/<account-name>/<resource-path>
Please reach to us if you have requirements or suggestions for a distributed Azurite implementation or higher performance.
Azurite is not a scalable storage service and does not support many concurrent clients. There is also no performance and TPS guarantee, they highly depend on the environments Azurite has deployed.
Please reach to us if you have requirements or suggestions for a specific error handling.
Azurite tries to align with Azure Storage error handling logic, and provides best-efforts alignment based on Azure Storage online documentation. But CANNOT provide 100% alignment, such as error messages (returned in error response body) maybe different (while error status code will align).
Azurite V3 follows a Try best to serve compatible strategy with Azure Storage API versions:
Azurite supports read-access geo-redundant replication (RA-GRS). For storage resources both in the cloud and in the local emulator, you can access the secondary location by appending -secondary to the account name. For example, the following address might be used for accessing a blob using the read-only secondary in Azurite:
http://127.0.0.1:10000/devstoreaccount1-secondary/mycontainer/myblob.txt
Both Azurite V3 and Azurite V2 aim to provide a convenient emulation for customers to quickly try out Azure Storage services locally. There are lots of differences between Azurite V3 and legacy Azurite V2.
Architecture in Azurite V3 has been refactored, it's more flexible and robust. It provides the flexibility to support following scenarios in the future:
Azurite V3 leverages a TypeScript server code generator based on Azure Storage REST API swagger specifications. This reduces manual efforts and ensures alignment with the API implementation.
Azurite V3 selected TypeScript as its' programming language, as this facilitates broad collaboration, whilst also ensuring quality.
Legacy Azurite V2 supports Azure Storage Blob, Queue and Table services.
Azurite V3 currently only supports Azure Storage blob service. Queue service is supported after V3.2.0-preview.
Table service support is currently under discussion.
Azurite V3 supports features from Azure Storage API version 2019-02-02, and will maintain parity with the latest API versions, in a more frequent update frequency than legacy Azurite V2.
Azurite V3 leverages a TypeScript Node.js Server Code Generator to generate the majority of code from Azure Storage REST APIs swagger specification.
Currently, the generator project is private, under development and only used by Azurite V3.
We have plans to make the TypeScript server generator public after Azurite V3 releases.
All the generated code is kept in generated
folder, including the generated middleware, request and response models.
3.3.0-preview release targets 2019-02-02 API version blob service.
Detailed support matrix:
Supported Vertical Features
Supported REST APIs
Following features or REST APIs are NOT supported or limited supported in this release (will support more features per customers feedback in future releases)
OAuth authentication
Access control based on conditional headers, container/blob lease (lease control is limited supported)
CORS and Preflight
Static Website
Soft delete & Undelete Blob
Put Block from URL
Incremental Copy Blob
Create Append Blob, Append Block
3.3.0-preview release added support for 2019-02-02 API version queue service. Detailed support matrix:
Supported Vertical Features
Supported REST APIs
Following features or REST APIs are NOT supported or limited supported in this release (will support more features per customers feedback in future releases)
This project is licensed under MIT.
Go to GitHub project page or GitHub issues for the milestone and TODO items we are used for tracking upcoming features and bug fixes.
We are currently working on Azurite V3 to implement the remaining Azure Storage REST APIs.
We finished the basic structure and majority of features in Blob Storage, as can be seen in the support matrix.
The detailed work items are also tracked in GitHub repository projects and issues.
Any contribution and suggestions for Azurite V3 is welcome, please goto CONTRIBUTION.md
for detailed contribution guidelines. Alternatively, you can open GitHub issues voting for any missing features in Azurite V3.
Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
2019.11 Version 3.3.0-preview
AZURITE_ACCOUNTS
.Blob:
Queue:
FAQs
An open source Azure Storage API compatible server
The npm package azurite receives a total of 444,241 weekly downloads. As such, azurite popularity was classified as popular.
We found that azurite demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 5 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.