I am trying to connect to the blog storage service with the Azure node.js sdk. This is what I am calling:
var blobService = azure.createBlobService(nconf.get("BlobStorage.account"),
nconf.get("BlobStorage.key"));
blobService.createContainerIfNotExist(
"test1"
, {publicAccessLevel : 'blob'}
, function(error){
if(error){
console.log(error);
}
});
This is the error I am getting:
code: 'AuthenticationFailed',
message: 'Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.\nRequestId:7ff326e7-2bc6-47ad-898e-2235dc26c03d\nTime:2013-03-15T19:45:25.0167404Z',
authenticationerrordetail: 'The MAC signature found in the HTTP request \'xg3cY11YCPo3mYPxDF5UV7cTPOErleERogcozwGVm6s=\' is not the same as any computed signature. Server used following string to sign: \'PUT\n\n\n0\n\n\n\n\n\n\n\n\nx-ms-blob-public-access:blob\nx-ms-date:Fri, 15 Mar 2013 19:45:25 GMT\nx-ms-version:2011-08-18\n/[containername removed for post]/test1%3Frestype=container\'.'
Can anyone point me in the right direction to resolve this issue?
Additional Details:
running on local machine, accessing azure blobstorage in the cloud
OS: Mountain Lion and Windows 8
Node version: 0.10.0
Azure NodeJS SDK version: 0.6.10
UPDATE - 3/15/13 1:23pm
Appears there is an issue with azure nodejs sdk 0.6.10 and node 0.10.
https://github.com/WindowsAzure/azure-sdk-for-node/issues/645
FYI Azure NodeJS SDK supports nodeJS upto 0.8.x for now.
#user1144313 we're aware that it's not working and are looking into it. http://codebetter.com/glennblock/2013/03/18/node-0-10-compat-issues-with-the-azure-sdk-and-cli/
For now please use node 0.8.x. As soon as we have the fixes in we'll be shipping updated versions. You can also check out wikis at https://github.com/windowsazure/azure-sdk-for-node and https://github.com/windowsazure/azure-sdk-tools which we will update as soon as we release updates.
Sorry for any inconvenience.
Related
TLDR:
Can't post to local Cosmos Emulator. Can post to Azure Cosmos, but not with #azure/cosmos-sign, only with #azure/cosmos (which seems utterly bizare as the latter is supposedly built upon the former.) This is not ideal (as the message signing portion alone is very lightweight with REST API directly). Bug, or user error? Why do the instructions for enabling networking/https not seem to work?
Details:
I have a Node.js based app, and am using the Azure/cosmos-sign package to generate the correct headers via the generateHeaders method to save a JSON object in the local Cosmos Emulator.
Upon trying to post from the Node app to the URI provided in the Emulator Quickstart (https://localhost:8081), the error returned is...
Error: connect ECONNREFUSED 127.0.0.1:8081 : https://localhost:8081
As per these instructions...
Enable access to emulator on a local network
If you have multiple machines using a single network, and if you set
up the emulator on one machine and want to access it from other
machine. In such case, you need to enable access to the emulator on a
local network.
You can run the emulator on a local network. To enable network access,
specify the /AllowNetworkAccess option at the command-line, which
also requires that you specify /Key=key_string or
/KeyFile=file_name. You can use /GenKeyFile=file_name to generate
a file with a random key upfront. Then you can pass that to
/KeyFile=file_name or /Key=contents_of_file.
To enable network access for the first time, the user should shut down
the emulator and delete the emulator's data directory
%LOCALAPPDATA%\CosmosDBEmulator.
-https://learn.microsoft.com/en-us/azure/cosmos-db/local-emulator?tabs=cli%2Cssl-netstd21#enable-access-to-emulator-on-a-local-network
...I thought perhaps I needed to enable the networking functionality. It is all on the same (Windows) host (with the Node.js application running in Docker on the same host as the Emulator is installed). But this caused more problems with no benefit. With the generated key, I can load the included UI for managing the local emulator instance, but I then can't create Databases or Containers (without resetting the emulator and starting it again normally, eg: without the AllowNetworkAccess and related settings).
Attempting to use the included Explorer to create a Database returns...
Error while creating database SampleDb:
{
"code": 401,
"body": {
"code": "Unauthorized",
"message": "The input authorization token can't serve the request. Please check that the expected payload is built as per the protocol, and check the key being used. Server used the following payload to sign: 'post\ndbs\n\nmon, 29 mar 2021 23:33:45 gmt\n\n'\r\nActivityId: 29e4e700-d1b7-4d59-bdea-5931e4d6622d, Microsoft.Azure.Documents.Common/2.11.0"
},
"headers": {
"access-control-allow-credentials": "true",
"access-control-allow-origin": "https://localhost:8081",
"access-control-expose-headers": "Access-Control-Allow-Origin,Access-Control-Allow-Credentials,Content-Type,x-ms-activity-id,x-ms-gatewayversion",
"content-type": "application/json",
"date": "Mon, 29 Mar 2021 23:33:45 GMT",
"server": "Microsoft-HTTPAPI/2.0",
"x-firefox-spdy": "h2",
"x-ms-activity-id": "29e4e700-d1b7-4d59-bdea-5931e4d6622d",
"x-ms-gatewayversion": "version=2.11.0",
"x-ms-throttle-retry-count": 0,
"x-ms-throttle-retry-wait-time-ms": 0
},
"activityId": "29e4e700-d1b7-4d59-bdea-5931e4d6622d"
}
I did see this somewhat similar SO question, but it was abandoned.
This one, however seems to imply they simply reverted the KeyFile steps mentioned in the MS Docs. It seems odd that I am getting the same error from the Node.js POST regardless of if I use the AllowNetworkAccess switch or not.
Using the /NoFirewall switch as recommended here didnt resolve POSTs but did allow the Explorer UI to still work properly. The upvoted answer for that question is what I have already tried (/AllowNetworkAccess /KeyFile=...., and is not working, as explained above).
The docs here indicate that TLS (https) is in fact required...
"The Azure Cosmos DB Emulator supports only secure communication via TLS"
However, here they seem to indicate that, in the Node SDK (which relies on the same cosmos-sign library I am using)...
"TLS verification is disabled. By default the Node.js SDK(version 1.10.1 or higher) for the SQL API will not try to use the TLS/SSL certificate when connecting to the local emulator."
I tried adjusting the start script for my Node Docker image as suggested here...
If connecting to the Cosmos DB Emulator, disable TLS verification
for your node process:
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
const client = new CosmosClient({ endpoint, key });
...and changed the start script in my package.json from...
"start": "node $NODE_OPTIONS node_modules...."
...to...
"start": "NODE_TLS_REJECT_UNAUTHORIZED=0 node $NODE_OPTIONS node_modules...."
...and rebuilt my images, but still receive the same ECONNREFUSED error from the Node client/app.
As I was reading the documentation for the REST API I was reminded that, as opposed to using the CosmosClient (which just needs the base URL), to do a post to the API the url needs to be fully formed as indicated here...
Method: POST
Request URI: https://{databaseaccount}.documents.azure.com/dbs/{db-id}/colls/{coll-id}/docs
Description: The {databaseaccount} is the name of the Azure Cosmos DB account created under your subscription. The {db-id} value is the
user generated name/ID of the database, not the system generated ID
(rid). The {coll-id} value is the name of the collection that contains
the document.
After appending /dbs/SampleDB/colls/SampleCollection/docs (yes, my entities are CamelCase) to the base url offered by the Emulator UI's Quickstart URI (https://localhost:8081)... I am still getting the ECONNREFUSED error to http posts.
Hmm... retargeted the Node app to point to a collection in my Azure Cosmos DB, and I am still having no luck.
400: Invalid API version. Ensure a valid x-ms-version header value is
passed. Please update to the latest version of Azure Cosmos DB
SDK.ActivityId: bfdeb339-8fef-4ba9-a03d-444a8664c02b,
Microsoft.Azure.Documents.Common/2.11.0
Added x-ms-version and set it to 2018-12-31 (latest, as per here).
Now I am getting (after trying both my secondary, and primary keys... just in case)...
401: The input authorization token can't serve the request. Please
check that the expected payload is built as per the protocol, and
check the key being used. Server used the following payload to sign:
'postdocsdbs/TopHand/colls/SampleTbltue, 30 mar 2021 02:54:25
gmt'ActivityId: bb258bb4-f5a8-4495-b0b5-b54fa8b7c46f,
Microsoft.Azure.Documents.Common/2.11.0
I verified that the required headers are all present. What can possibly be left?!
Base URI for Azure Cosmos had a trailing /, which ended up duplicated when the rest of the path was appended. Fixing the url string, still getting the 401.
A github issue pointed me to what may have been an error in the URL/REST path I was posting to. Rather than posting to (what I had previously)...
dbs/SampleDb/colls/SampleTbl/docs
...I changed it to...
dbs/SampleDb/colls/SampleTbl
...and am now getting error 405, MethodNotAllowed, RequestHandler.Post. 405 isn't listed as code returned by the Cosmos REST service.
This example in the MS docs definitely uses the /docs string at the end of the url/REST path.
Example
POST https://querydemo.documents.azure.com/dbs/1KtjAA==/colls/1KtjAImkcgw=/docs HTTP/1.1
x-ms-documentdb-partitionkey: ["Andersen"]
x-ms-date: Tue, 29 Mar 2016 02:28:29 GMT
authorization: type%3dmaster%26ver%3d1.0%26sig%3d92WMAkQv0Zu35zpKZD%2bcGSH%2b2SXd8HGxHIvJgxhO6%2fs%3d
Cache-Control: no-cache
User-Agent: Microsoft.Azure.Documents.Client/1.6.0.0
x-ms-version: 2015-12-16
Accept: application/json
Host: querydemo.documents.azure.com
Cookie: x-ms-session-token#0=602; x-ms-session-token=602
Content-Length: 344
Expect: 100-continue
{
"id": "AndersenFamily",
"LastName": "Andersen",
}
I contacted MS support and was giving some info that unblocked me (but doesn't entirely address the issues noted above).
For my own use-case, simply setting a key and allowing network access to the emulator was sufficient.
Note: This doesn't address the issues of the Emulator's Data Explorer becoming nonfunctional.
The feedback I received from the support personnel in regard to using the command line switches disabling the UI was...
By changing the key to something other than default one, you also
protect your emulator data from being seen via the Data Explorer.
Apparently the key alone isn't enough to protect the data, and disabling the UI is a "feature".
Solution: Simply executing...
.\Microsoft.Azure.Cosmos.Emulator.exe /AllowNetworkAccess /Key={insert your base64 encoded 64+ character string}
...allowed network access to systems on the same host as the emulator. This avoided all the certificate/key generation/importing/etc headache.
You must connect to the non-loopback IP of the host the emulator is running on to connect to it (writes/reads/etc).
I am using unity 2019.3 and installed latest azure speech SDKas far as I know. I also subscribed to pay as you go plan. Here is the error generated in unity:
CANCELED:
Reason=[Error]
ErrorDetails=[Connection was closed by the remote host. Error code: 1011. Error details: Internal server error. USP state: 3. Received audio size: 0bytes.]
Did you update the subscription info?
I have a function that is trigged by service bus with session enabled, but I get the error:
Microsoft.Azure.ServiceBus: It is not possible for an entity that requires sessions to create a non-sessionful message receiver
Is there a way to enable sessions with nodejs app?
I tried to edit my host.json but it didnt work, SessionHandlerOptions is not showing as property for serviceBus... "Property SessionHandlerOptions is not allowed"
{
"version": "2.0",
"extensions": {
"serviceBus": {
"SessionHandlerOptions": ....
}
}
}
}
Also tried to add "isSessionsEnabled": true in function.json but still getting same error.
Any idea?
This is a common question. Azure Functions don't support Service Bus sessions since Azure Function was create. This situation keeps for 3-4 years. Several months ago comes up a nuget package to Support this. For node.js I don't find a SDK to install. If you use C#, now it has a solution. But for node.js, I am not sure. You can have a try of the newest SDK, maybe it can support this.
This is an Function SDK issue. You can take a look.
So, after some hours and thanks to the suggestion from #BowmanZhu I found the solution that works also when using node.js.
Im using azure-functions-core-tools, so update it to latest version:
npm install -g azure-functions-core-tools#2
From the root map of the project install the package 3.1.1 of ServiceBus extension:
dotnet add package Microsoft.Azure.WebJobs.Extensions.ServiceBus --version 3.1.1
In the extensions.csproj file you should see now that the package reference for the package is 3.1.1
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.ServiceBus" Version="3.1.1" />
then run:
func extensions install
last add in function.json add in bindings:
"isSessionsEnabled": true
run func start to start the function app locally. You should not see anymore the error message and a queue with session enabled can be used to trig the function.
We have an AWS server running some nodeJS services. The services connecting to MS sql are randomly crashing with message "Failed to connect to databaseserver:1433 - Could not connect (sequence)".
We are running on:
App server:
Linux Ubuntu 14.4
AWS m5
NodeJS: 8.11.2
Services are using package mssql latest version (4.3.0). This includes tedious 2.7.1.
DB server:
Windows server 2012.
sql server 2012
throughput: about 300 rpm, error also happens when throughput is lower (about 20 rpm).
App is running in a cluster through PM2 (runs 4 times). We see the error happening on all 4 at the same time, but sometimes also on 1 or 2 instances.
What we tried:
Upgrading to alpha version of mssql with tedious 3.0.1. Did not make a difference
Upgrading from Amazon M4 machine to M5 machine with enhanced networking
Changing the pool settings in the app. We tried setting min connections to 0 or low/high value. Max also to low/high value but no avail.
Duplicate server to new machine.
Setting idleTimeoutMillis to 1 second
Pinging DB server to see if there is a connection problem, but we see no weird pings when the error happens.
Connection on app startup:
App.sqlConnection = new App.SQL.ConnectionPool(config, function(err) {
if(err){
Log.error(err);
process.exit(1);
}
App.sqlConnection.on('error', err => {
Log.error(`There was a connection err : ${err}`);
process.exit(1);
});
});
request;
var request = new App.SQL.Request(App.sqlConnection);
request.query(sQuery, function(err,results)
{
});
Errors are catched by the "on error" handler.
The error happens randomly across services. Some have more instances of the error then others.
We are running out of options. Any idea if we can see more detailed errors?
I have a couple suggestions.
First, how sure are you that these errors are actually a problem? If your code simply retries, instead of exiting, are the connections stable afterwards, or can a connection drop in the middle of a query?
(Connections dropping in the middle of queries are obviously not good, but random failures on connection, that can be fixed by retries, are the best kind of problem to have IMHO.)
Ignoring the potential in-code fix, I'm wondering when you say you "duplicated server to new machine" - did you launch a new AMI using latest Windows Server 2012, or did you image and clone? If your database server is a couple years old, you might actually be running outdated network drivers in your instance, which could give you some hiccups.
If you wanted to explore that, you could attempt rebuilding the entire database server from scratch on a newly launched AMI. Alternately you can upgrade PV driver, network adapter, and EC2Config on your existing instance, you can find the instructions at the following links:
https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Upgrading_PV_drivers.html#aws-pv-upgrade
https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/sriov-networking.html#enable-enhanced-networking
https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/UsingConfig_Install.html
When I load the SCCM consol on server its 5.0.8577.1000 but consol on my PC is 5.0.7958.1000
Its not giving me option to upgrade.
I can use the consol on server but I cant use it on my PC becasue its saying that Description = "Please upgrade your Admin Console to newer version";
I'm trying to update my PC with new version of consol but i'm not getting any way.
Can you please let me know why I cant upgrade?
SmsAdminUI.log
[5, PID:14856][06/25/2018 13:43:07] :System.Management.ManagementException\r\nGeneric failure \r\n at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementObject.InvokeMethod(String methodName, ManagementBaseObject inParameters, InvokeMethodOptions options)
at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, Boolean traceParameters)\r\nManagementException details:
instance of __ExtendedStatus
{
Description = "Please upgrade your Admin Console to newer version";
Operation = "ExecMethod";
ParameterInfo = "SMS_Identification";
ProviderName = "WinMgmt";
StatusCode = 2147749889;
};
SCCM info
OS: 2012 R2
SCCM 2012 1710
My PC
Windows 10 1802 Enterprise
I think the problem would be that the old console (2012 R2) was updated via a normal package by the server while the new version introduced with the multi annual releases (first version was 1511 I think and current version 1802) uses a self updating console.
So your server probably thinks the console will be self updating and the client thinks the server will update it.
On your site server there should be the full setup for the current console version
On our server there is a share:
\\SMS_\tools\ConsoleSetup (i hope this is universal, the local path from the server would be X:\Roles\ConfigMgr\tools\ConsoleSetup on the partition where your Roles are installed)
I would use this setup to update, or if it also fails to completely uninstall and reinstall the console. From then on it should auto-update with every new release.
Fix.
I copy the files from \SCCMSEEVER\SMS_Site\tools\ConsoleSetup to my PC and run the AdminConsole.msi
After doing this all is OK.