I am getting 400 bad request error while calling "/api/get_roster" endpoint of ejabberd. I had kept "get_roster" in the scope while requesting the oauth token.
400 bad request error in ejabberd
I guess there is some issue with the permissions. Here is my configuration file:
https://www.dropbox.com/s/his89bx39qhvr1h/ejabberd2.yml?dl=0
I have tried to follow the official documentation. As per the API permission guide, I have also tried adding following properties:
api_permissions:
- "Admin access":
- who:
- admin
- what
- "\*"
- "!stop"
But there was no change. I have following questions:
What am I doing wrong here?
What are possible scopes?
Your request should contain Authorization header as below:
curl -v -X POST -H "Authorization: Bearer <Oauth_token>" http://localhost:5280/api/get_roster -d '[]'
You can refer to this link for more details. If you are accessing as admin you can use commands_admin_access rule to provide access to api commands and specify the commands you want to access as follows:
commands:
- add_commands:
- get_roster
commands_admin_access: configure
You are using very old version of Ejabberd. Latest is 17.04 which has lots of changes in API permission framework from 16.01 . api_permission related configuration came in 16.12 version. Please refer this for more detail.
Related
I followed this tutorial:
https://www.serverlab.ca/tutorials/linux/administration-linux/how-to-install-hashicorp-vault-on-linux/
$ vault auth enable approle
Error enabling approle auth: Error making API request.
URL: POST http://localhost:8200/v1/sys/auth/approle
Code: 400. Errors:
* missing client token
my vault is running in a container and I have exposed it by 8200 port do I need to mount volumes ?
Use VAULT_TOKEN env while interacting with the vault server via vault CLI:
$ export VAULT_TOKEN="....."
That guide is missing the authentication step.
You will need to to provide a header in your curl request, for example
curl --header 'X-Vault-Token: s.5iSwFPh0XQa96MSrBHquCFlH' https://vault.blah/v1/...
I am trying to follow the istio gateway and Virtual Service guide at - https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports
I can see that these resources (Gateway & VS) are created from Kiali and also from command line. When I try to access my endpoint at curl -I -HHost:httpbin.example.com http://$INGRESS_HOST:$INGRESS_PORT/status/200 I get a 403 Forbidden error.
I am looking at the istio-proxy logs at
k logs httpbin-pod -c istio-proxy -n my-bookinfo
and dont see much there. I am trying to figure out where I can start to debug the issue. Any ideas? (edited)
I guess the HTTP 403 issue might be connected with Istio Authorization or Authentication mesh configurations, assuming that you've successfully injected Envoy sidecar into the particular Pod or widely across related namespaces.
The logs inspection might be most issue explainable task, confirming that Envoy's Access Logs are already enabled, you can look through relevant istio-proxy sidecar and istio-ingressgateway Pod logs; whereas you can fetch Envoy proxy response flags and traffic path workflow:
$ kubectl logs -l app=httpbin -c istio-proxy
[2019-03-06T09:31:27.360Z] "GET /status/418 HTTP/1.1" 418 - "-" 0 135
5 2 "-" "curl/7.60.0" "d209e46f-9ed5-9b61-bbdd-43e22662702a"
"httpbin:8000" "127.0.0.1:80"
inbound|8000|http|httpbin.default.svc.cluster.local - 172.30.146.73:80
172.30.146.82:38618 outbound_.8000_._.httpbin.default.svc.cluster.local
Check Authentication Policies within a mesh, that can affect sidecars proxy behavior and revise a global mesh policy in terms of mTLS authentication, Permissive mode is enabled by default:
$ kubectl get policies.authentication.istio.io --all-namespaces
$ kubectl get meshpolicy.authentication.istio.io default -oyaml
If you launched Authorization rules within a mesh, verify all the corresponded RBAC policies:
$ kubectl get clusterrbacconfigs.rbac.istio.io --all-namespaces
$ kubectl get authorizationpolicies.rbac.istio.io,rbacconfigs.rbac.istio.io,servicerolebindings.rbac.istio.io,serviceroles.rbac.istio.io --all-namespaces
Find more related information about troubleshooting steps in the official Istio documentation.
I am currently trying to complete this step by step tutorial which is based on Getting a 3-Legged Token with Authorization Code Grant
here is my cURL code:
curl -v "https://developer.api.autodesk.com/authentication/v1/gettoken"
-X POST
-H "Content-Type:application/x-www-form-urlencoded"
-d "client_id=****&
client_secret=****&
grant_type=authorization_code&
code=1O4F-z9gXRtGlBymcGoD3bV3Ws2cqqjeN78PpgGn&
redirect_uri=http://localhost:3000/api/forge/callback/oauth"
here is the error I am stuck with:
{"developerMessage":"The authorization code/refresh token is expired or
invalid/redirect_uri must have the same value as in the authorization
request.","userMessage":"","errorCode":"AUTH-004","more
info":"http://developer.api.autodesk.com/documentation/v1/errors/AUTH-004"}*
Connection #0 to host developer.api.autodesk.com left intact
Note:
I have double checked that the URI is the same as my callback URL on the forge application.
The spacing on the cURL code is simply for visual reasons, this is not how it is ran within my command line.
I think what's going on is that the code you get after the user logs in has an extremely short expiration time. After all, the POST /authentication/v1/gettoken endpoint is meant to be called immediately after the user logs in.
Btw. I went through the same steps, and since it took me a while to create a Postman request with the code I received, I ended up with the same error as you. Then, when I requested another code and immediately re-sent the Postman request, it succeeded.
I want to use Oauth2 and Spring-security with rest web service. I am new for this, i am trying to create configuration with the help of some websites. Still, i clearly not understand how and what is the flow for oauth authenticate for rest service. i am using latest dependencies Click on the link for see my configurations. I am using database for store clients information and tokens. when i trying to access the token, using follwoing url with post request and post body:
http://localhost:8080/empirecl-api/oauth/token
grant_type=password&username=a#a.com&password=password&client_id=my-client-with-secret&client_secret=ak_secret
The basic authentication pop-up box will appear. I am using chrome rest postman client. I have user table in my database where i store, username and password, when i enter those username and password, the authentication fail, If i use i my client_id and client_secret as a username and password, the authentication is fail. When i cancel the pop of basic authentication following json is return:
{
"error": "unauthorized",
"error_description": "No client with requested id: a#a.com"
}
I am unable to figure out what will happen.
When i trying to access following url with get reqquest:
http://localhost:8080/empirecl-api/oauth/authorize?grant_type=password&username=a#a.com&password=password
The following error will return:
{
"error": {
"error": "invalid_client",
"error_description": "Bad client credentials"
}
}
When i check the error in console, of eclipse, the follwoing error is display:
AuthorizationEndpoint:436 - Handling ClientRegistrationException error: No client with requested id: null
How i resolve this problem and how to use Oauth with my rest api. I also want to secure my all rest url with Oauth.
There are a couple of things wrong here.
You are using the wrong endpoint - the request should be to the token endpoint, not the authorization endpoint.
It should be a POST request - you shouldn't be passing the parameters in the URL
You are confusing when the user has to authenticate and when the client does - the server was looking for Basic credentials from the client but you were entering the username.
See the oauth2 spec section on using the resource owner password grant.
The client needs to authenticate and, as porterhead points out, you can do this using Basic authentication. The spec does also allow passing of the client id and secret as post parameters, but prefers Basic authentication.
You should probably make sure you understand a bit more about how OAuth2 works, and perhaps expand your question to explain why you want to use it and why you've chosen this particular grant type.
You need to pass your client username and password as a Base64 encoded Authorization header.
Try using curl. Here is an example:
curl -v -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Basic MzUzYjMwMmM0NDU3NGY1NjUwNDU2ODdlNTM0ZTdkNmE6Mjg2OTI0Njk3ZTYxNWE2NzJhNjQ2YTQ5MzU0NTY0NmM=" \
'http://localhost:8080/empirecl-api/oauth/token?grant_type=password&username=a#a.com&password=password'
I have a working example described here
As I couldn't find how to authenticate with the V2 API with my Box credential I tried to use the authentication token from a V1 API with a V2 request.
I discovered something weird and I'd like to know if something is wrong.
The documentation of the header to authenticate a V2 request described it like this for a curl command):
curl -k -L https://api.box.com/2.0/files/5053864602/content -H "Authorization: Bearer AUTH_TOKEN"
With curl I couldn't get anything, not even an error message.
However I tried this request with Postman and in the response I could see that the token was invalid.
In this forum I found that the header could have a different form including the api_key so I tried the following:
curl -k -L https://api.box.com/2.0/files/5053864602/content -H "Authorization: BoxAuth api_key=API_KEY&auth_token=AUTH_TOKEN"
and this request works as I could get the content of the file like with a V1 API call.
Could someone from BOX explains what's going on? I suspect that I'm not the only one having this problem...
The Box API now supports OAuth 2, which has a completely revised authentication flow. You can find the instructions on how to use OAuth 2.0 with Box here: http://developers.box.com/oauth/
V1-style auth is still also supported in the V2 API, though it will eventually be deprecated. However, if you're starting to build against the Box API now, you should use OAuth 2 in order to avoid having to do double work and port over in the future.
There are several differences between V1-style auth and OAuth 2.0, but notably in OAuth 2.0 you don't have to sign API requests with your API key (which is now called a 'client id' with OAuth 2.0), only the access_token you get through the auth process.
You can read more about our implementation of OAuth 2 in my previous link, and also about the spec in general here.