I have this webservice with OAuth2 authentication. I need to create a client for it in Delphi, so I'm using the "Rest Debugger", a tool from Embarcadero that helps configuring rest clients.
Problem is, I get the Bearer token from my webservice by other means, I add it in the headers (picture below), but the application returns "Cannot convert access token to JSON".
I know the token is valid, as I'm able to use it in other clients or tools (Postman, Swagger), it's just the "Rest Debugger" that gets this error from the server.
I would like to know what I'm doing wrong, or if there's some known issue with this specific tool. I've found some clues that suggests that by default it does some kind of encoding in the headers, but I would like to know for sure from someone more familiar with that tool.
Any help would be much appreciated.
In "REST Debugger" you must check "Do not encode" option when adding the Authorization header.
Related
I just move my website from Apache server to Litespeed server
I reconnect Zapier/integromat but it notices:
Error
401: Invalid response, response must be a XML. Parsed HTML response: 401 Unauthorized. 401. Unauthorized. Proper authorization is required to access this resource!. Proudly powered by Please be advised that LiteSpeed Technologies Inc. is not a web hosting company and, as such, has no control over content found on this site.
Please help me what reason and how to fix this. Thank you all.
more look like a migration problem instead of the Web server. You should contact your hosting company for details. They can switch between Apache and LSWS, also check the error log for you. You may also need to provide detailed URL for your hosting company to take a look.
I am trying to create a Google Assistant for my Raspberry Pi in Kotlin. I implemented a OAuth flow using the so called "device flow" proposed in this IETF draft, since my Raspberry shall later just expose a web interface and does not have any input devices or graphical interfaces.
Google does support this flow (of course) and I obtain a valid access token with user consent in the end. For testing purpose I also tried a default authorization flow that will just forward the user to localhost, as it is normally done but it did not solve the problem.
I tested the access token using this tool and it confirmed validity of scope and token. So the token itself should work.
Scope is: https://www.googleapis.com/auth/assistant-sdk-prototype as documented here
This actually does not point to any valid web resource but is referenced in every documentation.
Then I tried to stream audio data to the assistant SDK endpoint using the gRPC provided java stubs. As took a third party reference implementation as a guide how to authenticate the rpc stub. But neither the reference implementation nor my own one works. They both report
io.grpc.StatusRuntimeException: UNAUTHENTICATED: Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.
The stub is authenticated this way:
embeddedAssistantStub.withCallCredentials(
MoreCallCredentials.from(OAuth2Credentials
.newBuilder()
.setAccessToken(
myAccessToken,
myAccessTokenExpirationDate))
.build()))
and the authenticated request is performed like this:
val observer = authenticatedEmbeddedAssistantStub.converse(myStreamObserverImplementation)
observer.onNext(myConfigConverseRequest)
while(more audio data frames available) {
observer.onNext(myAudioFrameConverseRequest)
}
observer.onCompleted()
(I prefixed pseudo variables with "my" for clarity, they can consist of more code in the actual implementation.)
I even contacted the author of this demo implementation. He told me, last time he checked (several months ago) it was working perfectly fine. So I finally ran out of options.
Since the client implementation I took as reference used to work and I do actually authenticate the stub (although the error message suggests the opposite) Probably, either my valid access token with correct scope is not suitable chosen for the assistant API (though I followed the suggestions of google) or the API servers had a change not properly documented in the getting started articles by google.
So: Did anyone ran in the same problem and know how to fix it? I have the project on github. So if anyone needs the broken source code, I can do a temporary commit that produces the error.
Note, to save some works for mods: This issue referres to this and this question, both unresolved and using different languages but describing a similar problem.
Well, seems I was right about my second assumption: The error is server side. Here is the github issue, let's just wait for the fix.
https://github.com/googlesamples/assistant-sdk-python/issues/138
In Postman, I am able to successfully request a new token using the GUI. I'm wondering how to do this programatically. Or at least see the HTTP request that Postman is making. I've tried viewing it by monitoring the network traffic in Chrome, and with Wireshark, but without success. Thank you
well, OAuth2 is quite a big subject and you are not really providing a lot of details.
Postman is just a client, it creates requests based on the data you gave it so you don't need to monitor anything, you should know how you set it up and then simply mirror that in whatever language you want. Look at headers and post data specifically.
All I can do is point you to an extensive article I wrote on OAuth2, it shows a complete implementation, how to use Postman to create the correct requests and then how to write code which makes it all work.
If you don't use dot net, you can still understand all the concepts and it should be trivial to do the same thing using a different language.
https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/
I know this question may be so simple but still posting here.
I have a WebService/Restful API written in RAILS which gives response in JSON format. According to the RAILS developer, it works fine under his development but not in my case.
My problem is,
Now, I want to test that Request/Response in Browser Rest Client (like
mozilla, chrome). However, when I hit the API there it gives me 401.
So I have 2 questions,
1] How to test it in Rest Client? if I make any mistake while passing header parameter in wrong way.
2] Is there anything other approach to do this?
API Details are,
URL : http://rails4.xxxxx.com/xx/xxxxx/{id}.json
//{id} can be any integer value
header
X-xxxxxx-Client:
487txxxxhu34hfixxxxxu3hfcfxxxxx4f3f3f
For more details, please refer below snaps.
Thanks is advance.
There are a lot of ways to test rest api:
cURL (CLI)
RestConsole (for Chrome)
RestAssured (java test framework)
Frisby (javascript test framework)
Problem was due to wrong credentials.
We have realized that this URL http://Keyword:redacted#example.com/ redirects to http://example.com/ when copied and pasted into the browser's address bar.
As far as I understand this might be used in some ftp connections but we have no such use on our website. We are suspecting that we are targeted by an attack and have been warned by Google that we are passing PII (mostly email addresses) in our URL requests to their Google Adsense network. We have not been able to find the source, but we have been warned that the violation is in the form of http://Keyword:redacted#example.com/
How can we stop this from happening?
What URL redirect method we can use to not accept this and return an error message?
FYI I experienced a similar issue for a client website and followed up with Adsense support. The matter was escalated to a specialist team who investigated and determined that flagged violations with the format http://Keyword:redacted#example.com/ will be considered false positives. I'm not sure if this applies to all publishers or was specific to our case, but it might be worth following up with Adsense support.
There is nothing you can do. This is handled entirely by your browser long before it even thinks about "talking" to your server.
That's a strange URL for people to copy/paste into the browser's address bar unless they have been told/trained to do so. Your best bet is to tell them to STOP IT! :-)
I suppose you could look at the HTTP Authorization Headers and report an error if they come in populated... (This would $_SERVER['PHP_AUTH_USER'] in PHP.) I've never looked at these values when the header doesn't request them, so I'm not sure if it would work or not...
The syntax http://abc:def#something.com means you're sending userid='abc', password='def' as basic authentication parameters. Your browser will pull out the userid & password and send them along as authentication information, leaving the url without them.
As Peter Bowers mentioned, you could check the authorization headers and see if they're coming in that way, but you can't stop others from doing it if they want. If it happens a lot then I'd suspect that somewhere there's a web form asking users to enter their user/password and it's getting encoded that way. One way to sleuth it out would be to see if you can identify someone by the userid specified.
Having Keyword:redacted sounds odd. It's possible Google Adsense changed the values to avoid including confidential info.