AuthAzureSAS React Native Reference Documentation

AuthAzureSAS

Current Version: 11.6.1

Chilkat.AuthAzureSAS

Create Azure Shared Access Signature tokens for signed Azure Storage requests.

Chilkat.AuthAzureSAS creates Azure Shared Access Signature authentication tokens. It defines the SAS string-to-sign, supplies the Azure Storage account access key used to compute the signature, and controls which parameters are included in the generated SAS token query string. The resulting token can be used with Chilkat.Rest, Chilkat.Http, or other request-building code that needs time-limited, permission-scoped access to Azure Storage resources.

SAS token generation

Generate a signed query-string token that authorizes limited access to an Azure Storage resource.

String-to-sign control

Provide the exact Azure SAS string-to-sign required for the storage service and resource being accessed.

Account key signing

Use the Azure Storage account access key to compute the signature placed in the generated SAS token.

Token parameters

Add signed SAS parameters such as permissions, expiry, resource type, API version, protocol, or IP restrictions.

Non-token parameters

Add query parameters that should accompany the request but should not be included as part of the SAS token itself.

REST integration

Use the generated SAS query string with Azure Storage requests built using Chilkat.Rest or other Chilkat HTTP workflows.

Common pattern: Create an AuthAzureSAS object, set the Azure Storage AccessKey, provide the required StringToSign, add SAS token parameters with SetTokenParam, add any extra query parameters with SetNonTokenParam, then call GenerateToken. Use AuthAzureSAS when you need a SAS query token; use Chilkat.AuthAzureStorage when you need Shared Key authorization headers instead.

For an extended overview, see AuthAzureSAS Class Overview.

Object Creation

// npm install @chilkat/react-native react-native-nitro-modules
// (React Native 0.76+ with the New Architecture; then `pod install` for iOS.  The Chilkat
//  native library is downloaded and verified during the native build -- see the package README.)

import { Chilkat, AuthAzureSAS } from '@chilkat/react-native'

// Once per app start, before any other Chilkat call:
Chilkat.unlockBundle('Anything for 30-day trial')   // shorthand for new Global().unlockBundle(..)

const authAzureSAS = new AuthAzureSAS()
// ... the native object is released when `authAzureSAS` is garbage collected, or now with authAzureSAS.dispose()

new AuthAzureSAS()

Creates the underlying native Chilkat object. AuthAzureSAS is a Nitro Module HybridObject: use it from the JavaScript thread only (it cannot be passed to a Worklet or another runtime). Every member is synchronous and blocks the JavaScript thread until Chilkat returns; a method that can take a while also exists as a ...Async twin returning a Promise, which runs the same call on a native worker thread so the UI keeps rendering. While such a call is pending, every other call on this object throws, except abort() and assigning onPercentDone / onProgressInfo.

dispose(): void

Releases the native object immediately instead of waiting for garbage collection (useful for a large BinData or an open socket). Calling it more than once is harmless; any other use of the object afterwards throws. An object with a pending ...Async call cannot be disposed until the promise settles.

Errors

A method that can fail throws a plain Error: a method whose only outcome is success or failure returns void and throws on failure; a method producing a string or an object returns it and throws where Chilkat would have returned null. The error's message is "Class.method(...): reason", where the reason is the last informative line of the object's lastErrorText, which holds the full Chilkat log of the failed call. A ...Async twin rejects its promise with the same Error instead of throwing. Properties never throw, and methods that answer a question (has..., is..., ...) return a plain boolean.

try {
  authAzureSAS.someMethod(...)
} catch (e) {
  console.log((e as Error).message)   // AuthAzureSAS.someMethod(...): <reason>
  console.log(authAzureSAS.lastErrorText)   // the full Chilkat log of the failed call
}

// The same call without blocking the JavaScript thread:
try {
  await authAzureSAS.someMethodAsync(...)
} catch (e) {
  console.log((e as Error).message)   // AuthAzureSAS.someMethodAsync: <reason>
}

Properties

AccessKey

// read/write
accessKey: string

Introduced in version 9.5.0.65

This is the signing key (access key) that must be kept private. It is a base64 string such as abdTvCZFFoWUyre6erlNN+IOb9qhXgDsyhrxmZvpmxqFDwpl9oD0X9Fy0hIQa6L5UohznRLmkCtUYySO4Y2eaw==

More Information and Examples

How to Generate an Azure Service Bus Shared Access Signature (SAS)How to Generate an Azure Storage Account Shared Access Signature (SAS)

top

DebugLogFilePath

// read/write
debugLogFilePath: string

If set to a file path, this property logs the LastErrorText of each Chilkat method or property call to the specified file. This logging helps identify the context and history of Chilkat calls leading up to any crash or hang, aiding in debugging.

Enabling the VerboseLogging property provides more detailed information. This property is mainly used for debugging rare instances where a Chilkat method call causes a hang or crash, which should generally not happen.

Possible causes of hangs include:

A timeout property set to 0, indicating an infinite timeout.
A hang occurring within an event callback in the application code.
An internal bug in the Chilkat code causing the hang.

More Information and Examples

Example showing how to use DebugLogFilePath.

top

LastErrorHtml

// read-only
readonly lastErrorHtml: string

Provides HTML-formatted information about the last called method or property. If a method call fails or behaves unexpectedly, check this property for details. Note that information is available regardless of the method call's success.

top

LastErrorText

// read-only
readonly lastErrorText: string

Provides plain text information about the last called method or property. If a method call fails or behaves unexpectedly, check this property for details. Note that information is available regardless of the method call's success.

More Information and Examples

Concept of LastErrorText LastErrorText Standard Information

top

LastErrorXml

// read-only
readonly lastErrorXml: string

Provides XML-formatted information about the last called method or property. If a method call fails or behaves unexpectedly, check this property for details. Note that information is available regardless of the method call's success.

top

LastMethodSuccess

// read/write
lastMethodSuccess: boolean

Indicates the success or failure of the most recent method call: true means success, false means failure. This property remains unchanged by property setters or getters. This method is present to address challenges in checking for null or Nothing returns in certain programming languages. Note: This property does not apply to methods that return integer values or to boolean-returning methods where the boolean does not indicate success or failure.

top

StringToSign

// read/write
stringToSign: string

Introduced in version 9.5.0.65

Defines the format of the string to sign.

The format is specified as a comma-separated list of names. For example:

signedpermissions,signedstart,signedexpiry,canonicalizedresource,signedidentifier,signedIP,signedProtocol,signedversion,rscc,rscd,rsce,rscl,rsct

This will result in an actual string-to-sign that is composed of the values for each name separated by newline (LF) chars. For example:

signedpermissions + \n +  
signedstart + \n +  
signedexpiry + \n +  
canonicalizedresource + \n +  
signedidentifier + \n +  
signedIP + \n +  
signedProtocol + \n +  
signedversion + \n +  
rscc + \n +  
rscd + \n +  
rsce + \n +  
rscl + \n +  
rsct

More Information and Examples

Explaining Azure SAS Tokens

top

VerboseLogging

// read/write
verboseLogging: boolean

If set to true, then the contents of LastErrorText (or LastErrorXml, or LastErrorHtml) may contain more verbose information. The default value is false. Verbose logging should only be used for debugging. The potentially large quantity of logged information may adversely affect peformance.

top