I got a question -- I am trying to reuse the response from the ms-rest-nodeauth library. This way everytime I use my tool, I only need to authenticate if the authentication context is not valid.. Whenever I try to use the returned response I get this error
Error: credentials argument needs to implement signRequest method
Anyone got any suggestions?
If not already done then I believe that you would have to double check the code by leveraging the samples provided in this repo. If those samples are not helpful to resolve your error then raising an issue here / here would help you with better response from the repository contributors, etc.
Other references:
ms-rest-nodeauth (azure-sdk-for-js) : Error: credentials argument needs to implement signRequest method
https://github.com/Azure/azure-sdk-for-js/issues/3936
Related
I know a similar question has been asked (link), but the response didn't work for me.
TLDR: I keep running into errors when trying to authenticate Google Cloud Storage in RStudio. I'm not sure what is going wrong and would love advice.
I have downloaded both the GCS_AUTH_FILE (created a service account with service admin privileges'--downloaded the key associated with the service account) and also downloaded GAR_CLIENT_WEB_JSON by creating a OAuth 2.0 Client ID and downloading that associated JSON file.
I've tried authenticating my Google Cloud Storage in several ways and hit different errors.
Way 1-automatic setup:
gcs_setup()
Then I select any one of the options, and get the error: Error in if (file.exists(local_file)) { : argument is of length zero And that error happens no matter which of the three options I select.
Way 2 - basic, following manual setup instructions from the package:
Sys.setenv("GCS_DEFAULT_BUCKET" = "my-default-bucket",
"GCS_AUTH_FILE" = "/fullpath/to/service-auth.json")
gcs_auth()
In this case, GCS_AUTH_FILE is the file that I mentioned at the beginning of this post, and the GCS_DEFAULT_BUCKET is the name of the bucket. When I run the first line, it seems to be working (nothing goes awry and it runs just fine), but when I run gcs_auth() I get taken to a web browser page that states:
"Authorization Error
Error 400: invalid_request
Missing required parameter: client_id"
Way 3: Following the method from the post that I linked above
This way involves manually setting the .Renviron file w/ the GCS_AUTH_FILE and GAR__CLIENT_WEB_JSON locations, and then running gar_auth(). And yet again, I get the exact same error as in Way 2.
Any ideas about what could be going wrong? Thanks for your help. I wasn't sure how to put in totally reproducible code in this case, so if there is a way I should do that, please let me know.
I am trying to make a call for PriceQuoteService by importing new WSDL. There was an error while I tried to make the call where the auto-generated code of WSDL contained [][] instead of []. Upon making necessary replaces I am getting "Service provider invocation failure". I could not find mention of this error in all related documents.
I would like to know the cause and likely fix for this.
I am using heremaps calculate route api to get distance and time between two locations. I saw errors documentation and observed SYSTEM ERROR : errors that are thrown due to technical reasons. Can some one elaborate what might possibly lead to this type of error.
Usually routing API cause error because the documentation request contains spaces in the request-
https://route.ls.hereapi.com/routing/7.2/calculateroute.json
?apiKey={YOUR_API_KEY}
&waypoint0=geo!52.5,13.4
&waypoint1=geo!52.5,13.45
&mode=fastest;car;traffic:disabled
To avoid such type of error please remove all the spaces in the request like below-
https://route.ls.hereapi.com/routing/7.2/calculateroute.json?apiKey={}&waypoint0=geo!52.5,13.4&waypoint1=geo!52.5,13.45&mode=fastest;car;traffic:disabled
I am attempting to connect to a .Net 1.0 web service using standard activities in WF 4.0.
I am using the SendandReceiveReplyFactory - the send portion seems to be working - however the ReceiveReplyForSend is for some reason expecting a tempuri.org namespace response rather than the www.thermo.com/informatics/xmlns/limswebservice namespace.
Could anyone instruct me on how I can cause the activity to expect the correct NS.
Thanks in advance for your help.
All the best,
DJ
Error Message:
Workflow Console: Starting Workflow... Send Done Workflow
3fdc4d67-dcac-4092-b34b-9c347acdfe22 Terminated. Exception:
System.ServiceModel.CommunicationException Error in deserializing body
of reply message for operation 'Process'. OperationFormatter
encountered an invalid Message body. Expected to find node type
'Element' with name 'ProcessResponse' and namespace
'http://tempuri.org/'. Found node type 'Element' with name
'ProcessResponse' and namespace
'http://www.thermo.com/informatics/xmlns/limswebservice' Workflow
Console: Workflow Completed
The answer is to specify the namespace in the ServiceContractName Property of the 'Send' Activity using the following syntax '{http://someserver.org/test/}FileService ' in my case '{http://www.thermo.com/informatics/xmlns/limswebservice}LIMSSoap' . The syntax was sensitive to the trailing slash so a little trial and error was needed.
Many thanks to the contributors to WF4 - How to consume external web service? for the answer.
I am working session authentication. I am passing session id as token in cookie header. I wish to get encrypted token. which cryptable method should i prefer. I am using Digest::SHA, i got this error
The server encountered an internal error and was unable to complete your request.
Error message:
Attempt to reload Digest/SHA1.pm aborted. Compilation failed in require at /opt/lampp/htdocs/cts/login.pl line 21. BEGIN failed--compilation aborted at /opt/lampp/htdocs/cts/login.pl line 21.
what should do to overcome this error? Otherwise shall i use another one?
Try debugging your code. Take it through step by step, and look at the value of each variable. That might give you some insight, or at least give you a more specific understanding of why the program is failing to load. From the question you've given to us here, you really aren't giving us much to go off :)