I'm currently trying to implement IdentityServer4 to protect my API for an AngularJS 1.5 application using Azure Active Directory Crendentials.
So far it doesn't work and I'd like to investigate.
In the http response I get a cookie with an error message encoded in some form. I've tried to base64 decode it without success and I've been looking in the doc to understand what I should do with it, didn't find anything.
So the question is : how can I get a human understandable message from that?
Here is what it looks like
cookie:ErrorMessage.e5742c4e5414ab10614d79a3719775cc=CfDJ8M80lOqHw6FIvMiD9FvqmP6iVMyvAU6sHsPcbnmfFfRCFlq-PsSJvnEMlYZBrAsjqxFM9TBQClOuz9LjsyFmCfosPf9hFHUMvnHRXLN_DRXbnUvzEhatZO6GYQpfHcxlponK-4gtYUDXerZjVQz6YZiHbSPisTFmlLJTLa0-d2jrUGaQYZU456pxEnBe_jTdWjLzSKwP35z8Kd2aCMYv6iaOX2Fae01hqwgnDQHSBNyyz5uQ_fKxUg-ILI8ev0pe5xOppBZE2dA-Zp_WGYXJbHK4shxTtzi1WGIeOkOv_IOk; access_token=CfDJ8M80lOqHw6FIvMiD9FvqmP4IGJjkVW5oI3tqfqBxruMH0bptGzZF3QZql8nEzK1iglB4xjkTswbQG-EajSZdtCebZ_Ur-8PvsYJpZBgN0mcjwccyJZuPb7Dkhi1vjVUEtxn_SxZ7rM8o4sQiea0-y2M61e8RxxkOlIybLJl_KLbLgeu80ZFSgpDbVeMPeN2LJV7HTzHbLGQG3D7LO0qlSsCl0OOMpk7ijJqOSmS-deE4BXxyZLe-atSmTEih7n6BK9jnodQbuYMEkv7TQzI9Z9QQlCTzY8p6hYTDR3gQF_5QAlP21_fzXkz7FEI32VHyOF13tkzPr2xiw5nkbxdVP3v9cMMYfxqQMVi8mV0xihCKZWbRbbtm65aKsGxcR1uru88q21p6YhBYh_utlOhe4ipA5pmA7o0x1yoSGk36GZtadDjpGOSUhzTbykODLrKFqvxKofBoyL-rOAU78LRxhOR0Xo6H3NijVy45h6_XHftYs9rmsflDsoitTzogRIMmn9kFaaBDJo02QEDWWf2mcrKDOUd0Ej1An8uXLmUR4yNrYZTdrEdlL9G3G3yMlf0DP6AFbONWL9JMY9Y8JzTlyeLmTay2jgMayb8JARi5AG27VS687rD2YEe2P3py3pCUaLvFdc939EmGXa3YUZCtc3FoFOgSJt5FMs0N_6k6EST9bO5w4vCdmlNqO8QYzgLtBDbIAPqVzZharJv9tdy1kyk8ZB0nSILvAx1Lv4D1LPD7LOZe7beJLTov_AF0pmPJvpIH01F8t7DmPnjABFX01mtd7jySKdw35pGuF8_zHY4kHt8rFPbB1Qpjj5VoFvDLvfL6TfEZ46xCBENr6aftAR6vDee1smoIgkIKm-JEeNeT9vN4Gjn02sCNeFYAxD61ZGGI73jNmeOPklnbwA6vxKYavk7A9GKbcbaIv8JDkgIr0CCOsWunIJNNQiMM34tq_dVs13t2nYYKEAqdJqlplV9Dq3GqUQ31RFdtWg0Pmt2xogY3vjlCTnr8Jxr7ZOnPBL9dvTArodQVHsu9EKIwCi8kIRMOO8OheLbPEVfuyOWot3n5uw7CzZ7eB-1QjkKSgDeNHrFrxi8fI1hBychEloR_rykaA2otK7dpzTb6y8d3RnsqCzz2Y5BLRAzef4foThFZrcWSvhuWhzgg5OOsoP0qAuk4ujWju7SY1vetrXmbF16LSeBk_MIRsCjImH95A9RhyRgSsL2kmTcen5m_RoOHkr5xezSIjoDr2MhdJ-jnDEO8hV8SpdRzIpU-zXOHf3NrRsU55NGxg_Fk9_Ypxj6AKBX08V48lkyZo5MPXxflWNsO6N2azyGWQUiprDriQioek2HrDBu36ARiaAEtRxq918vByYbtbD-3qNqpqYePIDLBpddiS1HwbSU8sPSYQSwNMqewU32pfat4P8m2QJr_aUK4tQpD1vnmeltz1HNFAQesBN4e-bFWSQBF7Nk6RjoOVzErtH5BVyXHpuSCdOGSvNsczYRqVFl2jzJ6MppKGGfag-WPaisFbVr-uPspLJ2PFSMgRNsx-HRrax0WbxkMKdHAL2Q0-jt77pCdHUmMwqyoy-RHkRRC3osfPGyLyq37HSoGmf9Oct56uzSGUK92zK0mKT33CRjMFAGJyu0R4jMeSPINAh4MfgW9bGaqfr8QM24-W3meK5K4VMsB_3Rse_kRlzpsgciZXtkYlUlm2Ff8Na0g6lAAFH70gQ7WF8faPdB8cJrR2shYQUsL57cYsXe6un6yZF8IVTPlIv4ANepst0xdoZYD1fa_bywASqePkLVDf1Gj0xZw5BDqjrz2kGS52Ytj52y0XO5rMBL0R5D-uc-7n_CnO_ksf2CEeNrQf2GfZc94_Zr9Lc4FIr29cW8pKOVyvj5a9Fe6vqMJFXRNUmjBp6Oq7CyLwx3MNep1bZIoc1w44eyqtyCD0SZB-3uXeFsm-ODkHJYbCGF0n-EVL81J8FMmwOztqyu4bUcpAWxulM1NRGyngxTB4Lis_1jcP6IAtddZOLEXlLSB-PN0vM02o10H4oOArBi4beNhnW5GZTmRRkJh6ZmOnNdHA-NMyhFZhjl91K040anX_r4ZpAatg-GUR17BxhWxDNcAh5dWXYCreSWtOUKE-6Y5qrjQIfLgEAJZITLERNswuDevU8SnDGNamvWoNKJbAMCQfPcdZ14aIVkrNiZakuJJVn478ZHV9ATUB33xXAo5o95qGeOsR8rNd-84Y9K3lhXhg-bEi0I65vhmjKCQ6rpXwOKiKinD9_V3CcUGEmCjjslNMQqhfd17Jbn6LxuDfVPVwX9AKXZxo2MFr_E8ETY0cWH08pzsnFwUqnOY9MVWPjoZB-v6NdGOCUeBF_iLJ8pvCOK4RqLTyaqyJrm43F4fbbiNnXuk8GWWcqPSpGEm_0xD-NEjtBj2I7pERapMX2n3DOKlVeeGJe-LlSHIK4W5LvPowc46XDir6VbId17at1xGgFL0oNCx1i1VDnwm7QMvgjwJjiqdd4N-N8IfjR-QqweBg_yS7c5diDg41VwfSs2BmsXuZdS8_uRJG1u5_S4cPqhXxyYISn5iQNRneL0xaPPbNfaw4H3zChM6yY8nWgWnyziMtiEhYsgPXhnNI-4d9GCw-qqfg9u00x_S0O0eR9s9cBlqyQZ4lhGGjPAclbS1Q7QWE-lOdUpG1tAtpM3Pg5ItrfCyfX8xv5gNMU7RHyE7uKUTUT7kevcwh0QyftXTBjBdfddTfxGgWJAb3PM-YcU_2Tgp4jWpkS45UMCxeswcz4nWmEmNXuhtYlLoOcOZsCJNRySRBVTcoWW8CMAsGrJ8xk4ZzjoKwR-psEBFklYOtCT-AOx6ji_Zmkn-SzZMmUQ22po7ZxwgD8Mdtu7jEVO0zIsx2-NuMaghvHWnAHA35pT64Q6fPO2WGVqv1mFzq_A1fVoNZVc7O-QVs3iync5XVELlHOh5o9kBvKS9tNed7IOV-erRhzOZ36GOxe5H0Jd0VhmBGMWA2sQ8ePn8iaXtOA4LRI3DdX9Cf0-qFNQF5Gbf369-QYJbwY83xFqeE_A8LY4TF4gggswsCBz1T6xvzKBDo4KhXBAUzleXvpwHZGYkP8cslLk8AkwjXdwFohJZbXWnKpykmjmZEV0r6dBK7xtaIdqUFhEFK9I
Related
I recently picked up Nim and am in the process of re-implementing an existing web-application of mine to get some experience in the language.
This web-application used JWT for authentication, with the typical split into an access-token and a refesh-token.
The old way my application did refresh, was by receiving the refresh token via a POST request. The request body of that POST request would just be a raw JSON string and my application would grab the string off of that body and do its magic. The string would look like this:
{"refresh":"<JWT TOKEN STRING>"}
I've run into an issue when I wanted to access that raw JSON string in Prologue. There doesn't seem to be a way to do this.
When looking at the context's request, neither the PostParams nor the FormParams contain anything, they're empty. I can't find anything in the documentation about JSON-request bodies either and nothing in the source code looks like it is what I would want.
Is there no way for me to access the raw request body? Am I forced to change the way I send my refresh token?
After some more skillfull searching through the documentation I stumbled upon the answer I desired. There is a body() proc that allows you to access the raw HTTP body.
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.
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.
I'm developing a web application with golang and using an API of Twitter to do the login. It runs very well in my computer but I have that error when I put it in production.
Error getting request token, Post http://api.twitter.com/oauth/access_token: Call error 3: invalid security ticket
It's hard to tell without seeing the code, but I'd bet that your credentials are incorrect.
I'd recommend using a client library to handle your authentication to make debugging easier. (Here's a Go twitter client library I wrote).
If the error is that you're not creating the correct query, using a well-tested library will fix that. If you still get the same error, check that all of your credentials (including the callback URL!) are correct.
is it possible to submit forms with yahoo pipes?
i basically need to log in somewhere, and get some stuff from the members area of a website into a feed.
Although this is not exactly programming related... I guess it is close enough.
No, logging into somewhere is impossible with Yahoo Pipes. Sending the username/password isn't even the only problem here.
The real problem is that most, if not all, web sites that require a log-in depend on a session cookie or something similar. Yahoo pipes can do a GET request, and that's about it. Even if it was possible to send your user name/password in the URL, you would not be able to use the session cookie, so subsequent requests would fail.
So... If you have access to a hosted web site somewhere: Write a small proxy script (in PHP or whatever is available) that does the login and fetches the data. Let Yahoo pipes read from your proxy page. But if you are that far, you can just as well produce RSS format right away. ;-)
I did a pipe that can log in and extract info. is working ok on a simple web form using POST.