When I try to call:
https://sonar.mydomain.com/api/resources?resource=com.mydomain.project:MY&metrics=ncloc&format=json
I get
{"err_code":401,"err_msg":"Unauthorized"}
How do I pass my credentials?
According to the newest documentation said: SonarQube now support two way authentication:
User Token
This is the recommended way. Token is sent via the login field of HTTP basic authentication, this way will be more safety, without any password. For more information about how to generate a token, please visit this page User Token. Use curl send request like this:
curl -u THIS_IS_MY_TOKEN: https://sonarqube.com/api/user_tokens/search
# note that the colon after the token is required in curl to set an empty password
HTTP Basic Access
Login and password are sent via the standard HTTP Basic fields:
curl -u MY_LOGIN:MY_PASSWORD https://sonarqube.com/api/user_tokens/search
According to the documentation SonarQube uses basic authentication. Try:
curl -u admin:SuPeRsEcReT "https://sonar.mydomain.com/api/resources?resource=com.mydomain.project:MY&metrics=ncloc&format=json"
Obviously the mechanism for passing these credentials is dependent on how you are invoking the API.
This should also work from the web browser. Try logging into the Webui, your browser will normally cache the credentials.
This happens because authentication data does not include in your api call. This is how I solved it.
1.First install a rest client "Postman" to your browser.
2.Open it and put your API call url under "Normal" tab.
3.Go to "Basic Auth" tab and put username,password then click refresh headers.
4.Come back to "Normal" tab. You'll see a header named "Authorization" in header list.
5.Now click "send" button to view results.
6.If you are using 3rd party application, add "Authorization" header to your call with the value generated by postman.
Related
I am getting the apikey that generates the /api/login, but that apikey I don't see how to use it in the other endpoints since in the Docs it talks about making request with the OAuth2.
https://files.slack.com/files-pri/T11NA9FSN-F03CMAN5H6X/captura_desde_2022-04-22_15-38-11.png
In case you need to use
generated via "api/login" method API key in the scope of Sandbox you should:
generate API key via "api/login" method by passing login and password of customer user
sign in with the same user or just refresh Sandbox page, in case you already signed in
after authentication method will be changed to WSSE (in case if it is still session switch it manually)
after WSSE will be used for every call
In case you need to use WSSE authentication from code please see the next article (especially "Header Generation" part): https://doc.oroinc.com/api/authentication/wsse/
So I currently have all my requests set up in postman and to be able to make the request to my api I first need to go to the Authorization tab and click "Get Access Token" then a new window appears showing the log in screen from the Identity Server where I can enter the correct username and password to obtain the access token.
I am now wanting to use Postman to test my api however when the access token expires the tests of course fail.
What I want to know is the best way to approach setting up a script that could run the authorization before that request/tests are run.
I can see lots of examples if you only use ClientId and Secret however our Identity Server also requires the user to log in with username and password as that information is needed so that the Identity Info can be included in the returned token as the api called in the request uses this to determine which user to return data for.
Really hitting a brick wall here as I cannot see a way to automate the identity login.
How do others deal with running automated tests against an api protected with IdentityServer login?
You would have to mimic the set of requests and responses that would normally go through the browser. For example, you first make an authorization request. The server responds with a 302 to a login page. You can grab the location header and call the login page. Then you would post the username and password to the login form's action, etc.
You can have a look at this example: https://github.com/curityio/token-handler-node-express/blob/master/test/login.sh this is a set of curl commands which perform such login to an instance of the Curity Identity Server.
You should be able to script it as a series of requests in Postman.
I am developing a website which need google-login button. But i failed in getting the access_token.
Here is my configuration page and curl result.
why curl doesn't work.
The problem you are having is that you have created web browser credentials and you appear to be testing with curl. Curl by itself would be run in a command prompt or shell script there for it would be installed credentials not web browser credentials.
Go to google developer console and create desktop app type creetinals Then you can follow the calls below in order to authorize to Google and get an access token and a refresh token.
Notice how desktop apps use urn:ietf:wg:oauth:2.0:oob for a redirect uri this means just send it back where it came from.
# Client id from Google Developer console
# Client Secret from Google Developer console
# Scope this is a space separated list of the scopes of access you are requesting.
# Authorization link. Place this in a browser and copy the code that is returned after you accept the scopes.
https://accounts.google.com/o/oauth2/auth?client_id=[Application Client Id]&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=[Scopes]&response_type=code
# Exchange Authorization code for an access token and a refresh token.
curl \
--request POST \
--data "code=[Authentcation code from authorization link]&client_id=[Application Client Id]&client_secret=[Application Client Secret]&redirect_uri=urn:ietf:wg:oauth:2.0:oob&grant_type=authorization_code" \
https://accounts.google.com/o/oauth2/token
# Exchange a refresh token for a new access token.
curl \
--request POST \
--data 'client_id=[Application Client Id]&client_secret=[Application Client Secret]&refresh_token=[Refresh token granted by second step]&grant_type=refresh_token' \
https://accounts.google.com/o/oauth2/token
code ripped from GoogleAuthenticationCurl.sh
YOu may also be interested in Which type of credentials should you create? which explains how to decide which type of Google credentials you need to use for the application you are developing.
your web application.
Redirect uri mismatch with a true web application is most often a configuration issue. If you are using a servicer sided programming language you simply need to take the redirect uri that the error message is telling you is wrong and place that in Google Developer console for your web application as a Redirect uri. Google OAuth2: How the fix redirect_uri_mismatch error. Part 2
If on the other hand you have a Client sided web application using javascript it will state that the issue is with the JavaScript origin. It is still a configuration issue. However this time you need to take the URL it is telling you is wrong and place that in the javascript origin field in Google developer console Simple solution for redirect_uri_mismatch error with JavaScript
YOu do not need both Redirect URI and Javascript origin its one or the other.
Fixed it.
The problem is that i have added two version of redirect uri in the google console:
http and https
In the first step, i redirect customer to the oauth page "https://accounts.google.com/o/oauth2/v2/auth" with http version redirect uri.
In the second step i try to got the access token with https version redirect uri, so i got this error.
I maintain a private repository but want to make one file publicly available.
GitHub documentation states that the CURL command below can retrieve a file:
curl -u username:token https://api.github.com/user
But I would like to provide access through a URL. E.g.
https://username:token#raw.githubusercontent.com/me/repo/master/README.md
This always return a 404. Am I missing something?
From "How can I download a single raw file from a private github repo using the command line?", you wouldneed to use a PAT (Personnal Access Token) without the username:
curl -s https://$TOKEN#raw.githubusercontent.com/....
But I would not recommend making that token visible in any way: it would give access to that file and the rest of the repository.
Putting that file in a separate location (be it a separate public repository, or any other online text storage service) would be safer.
For those of you wondering the "why" on 404 vs 401, it's basically a security measure on GitHub's part to output 404 instead of 401: https://docs.github.com/en/github-ae#latest/rest/overview/other-authentication-methods#basic-authentication
For those wondering why we get a 404 in the browser while cURL gives us a success response, you might've assumed that providing the username and password in the URL like https://username:password#somesite.com would pass the credentials along in the initial request. That is not the case - the browser steps in and sees if the page you are requesting returns a WWW-Authenticate response header, and only then does it send your credentials. In the case of your GitHub url, the resource doesn't send back a WWW-Authenticate. If it did return WWW-Authenticate, then you obviously wouldn't run into this problem.
And then there's cURL. cURL assumes Basic Authentication by default and automatically sets the Authorization header to your username and password (either from the url like my previous example, or set through CLI options like in your example), and it sends it regardless of whether or not the server returns a WWW-Authenticate response header.
Unfortunately for us, there's no way to force the browser to send it with the initial request. As to why GitHub doesn't send a WWW-Authenticate response header, it's probably because they don't want to promote the least secure way of authentication - they no longer allow account passwords to be sent this way, after all. However, they do realize its ease of use and have mitigated some of its weaker points by allowing users to use oAuth access token, GitHub App installation access token, or Personal Access Token in its place that can limit its scope of access. So really, it's the browser that is following standards, and GitHub allowing a form of Basic Authentication with some alterations, and cURL immediately passing our credentials into the Authorization header. I believe the below is what's happening behind your requests:
cURL sends a request along with Authorization header → GitHub: "Well, I didn't ask, but yeah, your creds check out" → GitHub: Authorized and redirects to resource
Browser sends request and waits for WWW-Authenticate response before handing credentials → GitHub: "Umm, you don't have permission to access this resource but I can't let you know whether it actually exists") → GitHub: Returns 404 (instead of 401 with WWW-Authenticate header) stopping the browser short from receiving the WWW-Authenticate header response and sending out an Authorization header with the credentials on hand.
I am trying to build a frontend that for certain functionality needs to communicate with a Jenkins backend. In my frontend I want the user to be able to log in with the Jenkins credentials (username and password, using Kerberos) and have these passed to my Jenkins server, upon which I'd like to retrieve the token that can be used to make further API calls to the Jenkins server without disclosing the password in each request.
I know that to be able to make Jenkins API calls I need to use HTTP Basic auth, and it will accept both user:token and user:password. I want to avoid sending the password in each request though.
I also know that I can find my token by going to the Jenkins webpage, log in with my password, go to my profile page and find the token there. I can then base64 encode that into a functioning HTTP basic authentication header. This works fine.
However, I can't seem to find a decent way to programmatically authenticate using the password, trading the password for the token. The best I've been able to accomplish is to do a GET to said profile page at https://<JENKINS_HOST>/me/configure using the user:password basic auth header and then parse the resulting HTML for the api token, which obviously doesn't feel very robust:
$ curl -v --silent https://<USER:PASS#JENKINS_HOST>/me/configure 2>1
| sed -n 's/.*apiToken" value="\([^"]*\).*/\1/p'
<TOKEN>
What I expected/hoped to find was an API endpoint for authentication which would accept user/password and return the token in JSON format. For most Jenkins pages, the JSON API equivalent is found by simply appending /api/json to the URL, however /me/configure/api/json just throws a 404 at me. Does anyone know if there's such a way? All the docs I've found so far just tells you to go to the /me/configure webpage and look it up manually, which doesn't really make sense for a client wanting to pass along authentication.
Jenkins user API tokens are not exposed via the API.
I would just take the API token once manually from Jenkins and hardcode that (rather than hardcoding your password), since the API token never changes unless you explicitly reset it.
Alternatively, you could authenticate with your username and password and store the resulting value from the Set-Cookie header. Sending the cookie value in subsequent API calls would work as expected.