I can't authenticate into Azure Portal on my home desktop (Windows 10 Home). It just hangs with the following icon until I eventually get redirected to the error timeout page.
Interestingly I can still log into Office 365 and Azure DevOps, and I can also log in to the Azure Portal on my laptop. This makes me think it's related to my comp and not my Azure account.
I've tried the following:
Clearing cache, cookies, etc (in Chrome - latest version - Version 92.0.4515.107)
incognito mode (in Chrome)
different browsers - Edge/Opera
flushing dns
turning comp on/off
If I check the browser console in Chrome, there's a bunch of errors when trying to open the Azure portal e.g.
first couple errors in the console are:
MsPortalFx.Base.Diagnostics.ErrorReporter 1 MsPortalFx.Base.Diagnostics.ErrorReporter: {"message":"Request Error","responseHeaders":"cache-control: no-cache\r\ncontent-type: application/json; charset=utf-8\r\ndate: Sun, 25 Jul 2021 23:13:32 GMT\r\nexpires: -1\r\nnel: {\"report_to\":\"network-errors\",\"max_age\":86400,\"success_fraction\":0.001,\"failure_fraction\":1.0}\r\npragma: no-cache\r\nreport-to: {\"group\":\"network-errors\",\"max_age\":86400,\"endpoints\":[{\"url\":\"https://eafc.nelreports.net/api/report?cat=aportal\"}]}\r\nstrict-transport-security: max-age=31536000; includeSubDomains\r\nx-content-type-options: nosniff\r\nx-ms-version: 8.75.0.5 (production#6db687bbc5.210712-1125) Signed\r\nx-ua-compatible: IE=edge\r\nx-xss-protection: 1; mode=block\r\n","responseText":"{\"Message\":\"There was an error processing your request. Please try again in a few moments.\",\"HttpStatusCode\":\"InternalServerError\",\"XMsServerRequestId\":null,\"StackTrace\":null}","status":500,"statusText":"","uri":"/api/Portal/GetEarlyUserData?feature.internalgraphapiversion=true&feature.iris=true&feature.irismessagelimit=1&feature.showservicehealthalerts=true"}
MsPortalImpl/Services/Services.Settings 1 Services.Settings: _errorData: undefined
_sourceErrorLevel: undefined
baseTypes: ["MsPortalFx.Errors.Error"]
code: undefined
data: undefined
errorLevel: 2
extension: fx
handled: undefined
innerErrors: ["message: {\"message\":\"Request Error\",\"responseHeaders\":\"cache-control: no-cache\\r\\ncontent-type: application/json; charset=utf-8\\r\\ndate: Sun, 25 Jul 2021 23:13:32 GMT\\r\\nexpires: -1\\r\\nnel: {\\\"report_to\\\":\\\"network-errors\\\",\\\"max_age\\\":86400,\\\"success_fraction\\\":0.001,\\\"failure_fraction\\\":1.0}\\r\\npragma: no-cache\\r\\nreport-to: {\\\"group\\\":\\\"network-errors\\\",\\\"max_age\\\":86400,\\\"endpoints\\\":[{\\\"url\\\":\\\"https://eafc.nelreports.net/api/report?cat=aportal\\\"}]}\\r\\nstrict-transport-security: max-age=31536000; includeSubDomains\\r\\nx-content-type-options: nosniff\\r\\nx-ms-version: 8.75.0.5 (production#6db687bbc5.210712-1125) Signed\\r\\nx-ua-compatible: IE=edge\\r\\nx-xss-protection: 1; mode=block\\r\\n\",\"responseText\":\"{\\\"Message\\\":\\\"There was an error processing your request. Please try again in a few moments.\\\",\\\"HttpStatusCode\\\":\\\"InternalServerError\\\",\\\"XMsServerRequestId\\\":null,\\\"StackTrace\\\":null}\",\"status\":500,\"statusText\":\"\",\"uri\":\"/api/Portal/GetEarlyUserData?feature.internalgraphapiversion=true&feature.iris=true&feature.irismessagelimit=1&feature.showservicehealthalerts=true\"}\r\nstack: Error: {\"message\":\"Request Error\",\"responseHeaders\":\"cache-control: no-cache\\r\\ncontent-type: application/json; charset=utf-8\\r\\ndate: Sun, 25 Jul 2021 23:13:32 GMT\\r\\nexpires: -1\\r\\nnel: {\\\"report_to\\\":\\\"network-errors\\\",\\\"max_age\\\":86400,\\\"success_fraction\\\":0.001,\\\"failure_fraction\\\":1.0}\\r\\npragma: no-cache\\r\\nreport-to: {\\\"group\\\":\\\"network-errors\\\",\\\"max_age\\\":86400,\\\"endpoints\\\":[{\\\"url\\\":\\\"https://eafc.nelreports.net/api/report?cat=aportal\\\"}]}\\r\\nstrict-transport-security: max-age=31536000; includeSubDomains\\r\\nx-content-type-options: nosniff\\r\\nx-ms-version: 8.75.0.5 (production#6db687bbc5.210712-1125) Signed\\r\\nx-ua-compatible: IE=edge\\r\\nx-xss-protection: 1; mode=block\\r\\n\",\"responseText\":\"{\\\"Message\\\":\\\"There was an error processing your request. Please try again in a few moments.\\\",\\\"HttpStatusCode\\\":\\\"InternalServerError\\\",\\\"XMsServerRequestId\\\":null,\\\"StackTrace\\\":null}\",\"status\":500,\"statusText\":\"\",\"uri\":\"/api/Portal/GetEarlyUserData?feature.internalgraphapiversion=true&feature.iris=true&feature.irismessagelimit=1&feature.showservicehealthalerts=true\"}\n at XMLHttpRequest.<anonymous> (https://portal.azure.com/?bundlingKind=DefaultPartitioner&configHash=3HVigcPjEhD-&env=portal&helppanenewdesign=true&helppanevmproblemcards=false&l=en.en-us&moveresourcesreact=true&pageVersion=8.75.0.566875.210712-1125:12:363)\r\n"]
message: Early Failed to preload stores.
name: Error
source: undefined
stack: Error: Early Failed to preload stores.
at new t (https://portal.azure.com/Content/Dynamic/LIXabXGijvQo.js:83:882)
at https://portal.azure.com/Content/Dynamic/IUr50ifbdDUb.js:62:6538
timestamp: 734.0999999642372
type: MsPortalFx.Errors.Error
I am having the same issue and have figured out what was causing it. My antivirus, I use Free BitDefender. When I disable the protection I can then access azure.
As a temporary workaround, use Brave browser. Chrome, Edge, Firefox or Opera have the problem.
I'm experiencing exactly the same thing. I can log in fine on other computers and my mobile
Running https://portal.azure.com/selfhelp can possibly help you diagnose issues that would cause an issue like this.
Related
I have one old Azure Functions project (v3). It contains several timer triggered functions. They stopped working on VS2022. You can see the logs below. If I create a new Functions project via VS2022, it will work fine. Looks like Azurite also starts up fine. Setting "AzureWebJobsStorage" equals "UseDevelopmentStorage=true". What can I do?
[2022-01-06T10:17:15.675Z] Host lock lease acquired by instance ID '000000000000000000000000DC2A3C3E'.
[2022-01-06T10:17:35.554Z] The listener for function 'Function1' was unable to start.
[2022-01-06T10:17:35.556Z] The listener for function 'Function1' was unable to start. Azure.Storage.Blobs: Service request failed.
[2022-01-06T10:17:35.557Z] Status: 500 (Internal Server Error)
[2022-01-06T10:17:35.557Z]
[2022-01-06T10:17:35.558Z] Headers:
[2022-01-06T10:17:35.559Z] Server: Azurite-Blob/3.14.1
[2022-01-06T10:17:35.560Z] ETag: "0x234B8B049DD4280"
[2022-01-06T10:17:35.561Z] x-ms-blob-type: BlockBlob
[2022-01-06T10:17:35.562Z] x-ms-lease-state: available
[2022-01-06T10:17:35.562Z] x-ms-lease-status: unlocked
[2022-01-06T10:17:35.563Z] x-ms-client-request-id: a3bc0141-7bcb-420c-84a9-eadf86f8c685
[2022-01-06T10:17:35.564Z] x-ms-request-id: 88474d4b-bc15-4f45-95d5-0a01682d883d
[2022-01-06T10:17:35.565Z] x-ms-version: 2020-10-02
[2022-01-06T10:17:35.566Z] Accept-Ranges: bytes
[2022-01-06T10:17:35.566Z] Date: Thu, 06 Jan 2022 10:17:35 GMT
[2022-01-06T10:17:35.567Z] x-ms-server-encrypted: true
[2022-01-06T10:17:35.570Z] x-ms-blob-content-md5: jhxvLoUrRfc2dXn/gXokig==
[2022-01-06T10:17:35.570Z] Connection: keep-alive
[2022-01-06T10:17:35.571Z] Keep-Alive: REDACTED
[2022-01-06T10:17:35.572Z] Last-Modified: Tue, 28 Dec 2021 11:10:44 GMT
[2022-01-06T10:17:35.573Z] Content-Length: 115
[2022-01-06T10:17:35.574Z] Content-Type: application/octet-stream
[2022-01-06T10:17:35.574Z] Content-MD5: jhxvLoUrRfc2dXn/gXokig==
UPDATE
I have added few new functions to the same project. They work fine. I have changed function and method names and old functions also start working. Looks like it caches somewhere names. I tried clean rebuild but it didn't help. I have no idea why it doesn't work with old names.
I was able to solve this issue by using Azure Storage Explorer and deleting the related blob folder under azure-webjobs-hosts in the local storage blob container
The root folders will be found at:
Local & Attached > Storage Accounts > (Emulator - Default Ports) > Blob Containers -> azure-webjobs-hosts
Make sure the project is open or Storage Explorer may not load the containers.
Once deleted, the problem function began running as expected
Created the Azure Functions v3 Project in Visual Studio 2019 along with the azurite extension to the project and running locally:
Same Code opened in VS 2022 and run the function locally:
As given in the Microsoft Documentation, Azurite is automatically available with the VS 2022.
When you open the Azure Functions v3 project (earlier created in VS 2019) in VS 2022 now, it might show this messages in the output dialog box after loading the dependencies:
Still, the Azure Storage Emulator is required to run any azure functions project in the Windows, it needs to be installed in the system.
Make sure the Azure Storage Emulator is installed and the azurite is a future storage emulator platform included with VS 2022. If you're using earlier Visual Studio, you'll need to install Azurite by using either Node Package Manager, DockerHub, or by cloning the Azurite github repository given in the following documentation.
I have this nagging error message on accessing an endpoint on azure portal.
Any one could help?
HTTP/1.1 401 Unauthorized
cache-control: none
content-length: 0
content-security-policy: script-src 'self'
date: Tue, 23 Nov 2021 16:47:15 GMT
expect-ct: max-age=604800,enforce
ocp-apim-apiid: cash-code
ocp-apim-operationid: generate-cashcode
ocp-apim-subscriptionid: master
For me this was simply a case of using the wrong "secret" i.e. I accidentally used the SecretID instead of the value of the secret.
That was allowing me to get a code without an error message, but the code was not actually valid even though it looked like a proper code, and all I got back was the infamous 401 without a clue as to why it was happening.
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 want to integrate automatic digital signature capabilities in my application. I signed-up for DocuSign sandbox account and tried to build and run example code from https://github.com/docusign/docusign-signature-appliance-api-recipes/tree/master/dsa-rest/Hello-World-examples
While running java hello-world example I am getting error as
Feb 09, 2021 9:01:00 AM org.apache.http.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://prime-dsa-devctr.docusign.net:8081: Connection reset by peer: socket write error
Feb 09, 2021 9:01:00 AM org.apache.http.impl.execchain.RetryExec execute
I tried running C# code also , but get similar error in calling REST Endpoint "https://prime-dsa-devctr.docusign.net:8081/sapiws/v1/digital_signature"
The underlying connection was closed: An unexpected error occurred on a receive
am I missing something here? I tried changing user credential used in code, but still error does not change.
Update: the issue should be resolved now.
The DSA team is working on this, this is not your issue. It's down at least when I'm typing this answer. I'll update it as soon as it's back up.
I'm setting up Azure Storage Emulator but when I attempt to put a blob in to a container, I get the above exception.
I'm working with Windows Azure Storage Emulator 4.4.0.0.
I get the same error in my code (versions 4.3.0.0 and 7.0.0.0 of Microsoft.WindowsAzure.Storage), as well as latest version of Microsoft Azure Storage Explorer (0.7.20160509.0). In code, the failing method is CloudBlockBlob.UploadFromStream(myStream source).
I've hooked up Fiddler proxy and compared the request to the Azure Blob REST API, and it looks ok to me.
Request:
PUT http://127.0.0.1:10000/devstoreaccount1/public/broker/broker_placeholderLogo.png HTTP/1.1
User-Agent: Azure-Storage/7.0.0 (.NET CLR 4.0.30319.42000; Win32NT 10.0.10586.0)
x-ms-version: 2015-07-08
Content-MD5: 1/VCBZRjnuUQPBtMviZfzw==
x-ms-blob-type: BlockBlob
x-ms-client-request-id: fec3ada1-653b-46ec-81f0-a1602baab494
x-ms-date: Wed, 25 May 2016 14:01:17 GMT
Authorization: SharedKey devstoreaccount1:60ts48q7J714f74GWTA3sbICqGvxqg2NXPWjZQH/IXA=
Host: 127.0.0.1:10000
Content-Length: 10748
Response:
HTTP/1.1 400 One of the request inputs is not valid.
Content-Length: 220
Content-Type: application/xml
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 8882fa90-80d0-4043-a997-836f645bc349
x-ms-version: 2015-07-08
Date: Wed, 25 May 2016 14:01:17 GMT
<?xml version="1.0" encoding="utf-8"?><Error><Code>InvalidInput</Code><Message>One of the request inputs is not valid.
RequestId:8882fa90-80d0-4043-a997-836f645bc349
Time:2016-05-25T14:01:17.5245914Z</Message></Error>
The containers are being created fine, so I don't think it's a problem with authorisation. I'm running out of ideas on what might be causing this issue.
UPDATE: I've tried removing the MD5 validation, but it made no difference.
Try to solve it by installing version 4.3.0.0. Had the same problem today and that worked perfectly
Currently, it is still possible to download version 4.3.0.0 by going to https://azure.microsoft.com/en-us/downloads/ (Section: Command-line tools) and downloading the standalone package of the Azure Storage Emulator.
We've investigated the issue and have determined it affects a subset of customers. We are currently testing a hot fix to address the issue; until then, please stay on 4.3. We apologize for the inconvenience.
[UPDATE] An updated version of 4.4 is now available which should address this issue.
I had the same issue on iOS. The problem was in request's default cache policy, it silently added If-None-Match header. Adding [request setCachePolicy: NSURLRequestReloadIgnoringLocalCacheData]; fixed the problem for me.