I have followed this blog for spring oauth jwt: https://medium.com/#nydiarra/secure-a-spring-boot-rest-api-with-json-web-token-reference-to-angular-integration-e57a25806c50
In a browser like Chrome or IE edge, when I go to https://infinite-tundra-6984.herokuapp.com/springjwt/cities, I am prompted to enter username and password.
For standard user:
username: john.doe
password: jwtpass
For Admin:
username: admin.admin
password: jwtpass
It works as expected.
However, when I use curl:
curl testjwtclientid:MaYzkSjmkzPC57L#infinite-tundra-6984.herokuapp.com/oauth/token -d grant_type=password -d username=admin.admin -d password=jwtpass
I get a token like:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsidGVzdGp3dHJlc291cmNlaWQiXSwidXNlcl9uYW1lIjoiYWRtaW4uYWRtaW4iLCJzY29wZSI6WyJyZWFkIiwid3JpdGUiXSwiZXhwIjoxNTA4MTMxNzQwLCJhdXRob3JpdGllcyI6WyJTVEFOREFSRF9VU0VSIiwiQURNSU5fVVNFUiJdLCJqdGkiOiIyNjVmYmY5OS0wYWU3LTQ0MmQtOThjNy03ZTkxMmFhYWZlNWYiLCJjbGllbnRfaWQiOiJ0ZXN0and0Y2xpZW50aWQifQ.exXHqinGAfoPYLFYxhiWIsEg1FSSHxw34Snxdk0AqnU
Then I do:
curl https://infinite-tundra-6984.herokuapp.com/springjwt/cities -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsidGVzdGp3dHJlc291cmNlaWQiXSwidXNlcl9uYW1lIjoiYWRtaW4uYWRtaW4iLCJzY29wZSI6WyJyZWFkIiwid3JpdGUiXSwiZXhwIjoxNTA4MTMxNzQwLCJhdXRob3JpdGllcyI6WyJTVEFOREFSRF9VU0VSIiwiQURNSU5fVVNFUiJdLCJqdGkiOiIyNjVmYmY5OS0wYWU3LTQ0MmQtOThjNy03ZTkxMmFhYWZlNWYiLCJjbGllbnRfaWQiOiJ0ZXN0and0Y2xpZW50aWQifQ.exXHqinGAfoPYLFYxhiWIsEg1FSSHxw34Snxdk0AqnU"
I get a 401
Can someone give me some hints on the differences between the two ways of accessing secured content?
It seems like, with the curl/token access, it can't figure out my role
I missed this step.
In application.properties, I need to add this line:
security.oauth2.resource.filter-order = 3
This has caused me so much time
Related
I have a very minimal spring-boot app with dependency spring-boot-starter-web and spring-boot-starter-security. I just learned spring boot yesterday. I noticed that sending a POST request like below even if provided with the wrong basic auth password the request succeeds. Because, of the presence of a cookie in a previous successful request.
curl --location --request POST 'http://localhost:8080/create' --header 'Content-Type: application/json' --header 'Cookie: JSESSIONID=EA39A09B47575D192845148AFFCAD85B' --data-raw '{
"surname":"Murdock",
"givenname":"John",
"placeofbirth":"Slovenia",
"pin":"1234"
}'
Is this the expected behavior? And how do I make spring-boot to always check the provided basic auth password?
I have the following problem that my curl request with login isn’t working. I tried different things I saw on stack overflow but I couldn’t get this working.
My AXIS-Camera has an API to access some data like the date and much more. On the browser I use a link like this:
http://root:root#IP/axis-cgi/date.cgi?action=get
The feedback is this:
Nov 20, 2017 14:27:00
Using curl:
curl "http://root:root#IP/axis-cgi/date.cgi?action=get"
or:
curl –user "root:root" "http://IP/axis-cgi/date.cgi?action=get"
I always get this result:
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body></html>
Axis requires Digest mode for the auth, and curl doesn't use it by default.
Try this:
curl --digest -u root:root http://IP/axis-cgi/date.cgi?action=get
I did this on an Axis 231D+ PTZ that I'm trying to figure out. Firmware 4.47. API version is probably really old. But this worked:
curl http://user:pass#host/axis-cgi/admin/date.cgi?action=get
I've been looking through the cgi directories trying to figure out where stuff lives. I think you may have missed a directory in your path. Or this camera has it in a different place. Hope this helps someone else too.
I do:
curl --digest -u user:pass http://host/axis-cgi/admin/uptime.cgi
And it does this:
<HTML><HEAD><TITLE>401 Unauthorized</TITLE></HEAD>
<BODY><H1>401 Unauthorized</H1>
Your client does not have permission to get URL /axis-cgi/admin/uptime.cgi from this server.
</BODY></HTML
I want to use passport-local to authenticate user to login into composer rest server like other passport strategies ( e.g passport-github,passport-google).
So first I try to set COMPOSER_PROVIDER variable like this
"local": {
"provider": "local",
"module": "passport-local",
"usernameField": "username",
"passwordField": "password",
"authPath": "/auth/local",
"successRedirect": "/",
"failureRedirect": "/"}
Then i run the server in docker (with mongo as persisted datasource) and add some user in database collection
The question is what's next step that i need to use this passport.Because i run this command and still get response with 401 Unauthorized
curl -H "Content-Type: application/json" -X POST -d
'{"username":"{USER_NAME}","password":"{USER_PASSWORD}"}'
http://localhost:3000/auth/local
Is it not enough to use this passport? Does i need to start another service to locally authenticate this login (e.g. GitHub oAuth Application )?
It is possible to customize your composer-rest-server, based on the loopback framework, according to your requirements.
I suggest to read this tutorial from the official documentation.
https://hyperledger.github.io/composer/latest/integrating/customizing-the-rest-server
I wanted to do that also initially, but then I just edit the server.js file on the composer rest server for basic auth at the end.
check where your composer-rest-server is stored
npm root -g
Open where server.js is located
cd /home/ubuntu/.nvm/versions/node/v8.10.0/lib/node_modules/composer-rest-server/server
Add this to the code
const basicauth = require('basicauth-middleware');
app.use(basicauth('username', 'password!');
we try to automate the creation of projects (including user/group Management) in sonarqube and I already found the Web-API-documentation in our sonarqube 5.6-Installation. But if I try to create a project with the following settings
JSON-File create-project.json:
{"key": "test1", "name": "Testprojekt1"}
curl-request
curl --noproxy '*' -D -X POST -k -u admin:admin -H 'content-type: application/json' -d create_project.json http://localhost:9000/api/projects/create
I get the Error:
{"err_code":400,"err_msg":"Missing parameter: key"}
It's a bit strange because if I try e.g. the URL:
http://localhost:9000/api/projects/index
I get the list of the projects I created manuelly and if I try a request like
curl -u admin:admin -X POST 'http://localhost:9000/api/projects/create?key=myKey&name=myProject'
it works too, but I would like to use the new api because it looks like it support much more function that the 4.X API of sonarqube.
Maybe someone here can help me with this problem, if would very thanksful for every useful hint.
best regards
Dan
I found this question because I got the same "parameter missing" error message.
So what we both did not understand: The SQ API expects the parameters as plain URL parameters and not as json formatted parameters as most REST APIs do today.
PS: Would be nice if this could be added to the SQ documentation.
My understanding of the process:
From mediawikis login manual https://www.mediawiki.org/wiki/API:Login
When using MediaWiki's web service API, you will probably need your application or client to log in. This involves submitting a login query, constructing a cookie, and confirming the login by resubmitting the login request with the confirmation token returned.
1) Attempt to login with username and password, this will fail with 'result="NeedToken"' as part of response html. Response will also contain the token to be passed in for the next login attempt.
2) Attempt to login again, this time passing in token in addition to un/pw. This should return with 'result="Success"'
My code:
###Attempt first login setup cookie jar
loginRes1=$(curl --cookie-jar cjar -X POST "$domain/wiki/api.php?action=login&lgname=$lgname&lgpassword=$lgpassword")
###Grab the token from login attempt
lgtoken=$(echo $loginRes1 |sed -rn "s/.*token="([0-9a-zA-Z]+)".*/\1/p" )
###Attempt second login, this time passing token as well
loginRes2=$(curl --cookie-jar cjar -X POST "$domain/wiki/api.php?action=login&lgname=$lgname&lgpassword=$lgpassword&lgtoken=$lgtoken")
Result:
echo $loginRes1
###Only relevant html from echo shown below, cleaned up into xml syntax
<?xml version="1.0"?> <api> <login result="NeedToken" token="944af711913a037cfb8b90d477d51f6c" cookieprefix="ronk" sessionid="isqvhm955lj35g1q2e2klme091" /> </api>
echo $loginRes2
###Only relevant html from echo shown below, cleaned up into xml syntax
<?xml version="1.0"?> <api> <login result="NeedToken" token="ffdd1aa6dc3699df26b9de6dd1c6d5a5" cookieprefix="ronk" sessionid="fdahoh4gh7junrqm1tk2p1qd25" /> </api>
I'm still getting the NeedToken result the second time, instead of Success as I would expect.
Logging in via browser
I can login normally with a browser with a form submission, the post request contains 4 parameters: wpName, wpPassword, wpLoginAttempt, wpLoginToken
wpName=myName&wpPassword=myPassword&wpLoginAttempt=Log+in&wpLoginToken=d3fe3a1de6fbc934acd3039149f3c56d
Other Notes
1) I confirmed that the un/pw works when logging in normally through a browser.
2) It's unclear to me if I'm using the curl cookie-jar syntax appropriately
3) I don't know the version of mediawiki I'm connecting to, it was installed recently and is likely the highest stable version.
4) You'll notice in the successful browser attempt, the parameters have the wp prefix instead of lg, if I change the curl attempt to match (i.e. wpName, wpPassword) then the returned result is:
<?xml version="1.0"?> <api> <warnings> <main xml:space="preserve">Unrecognized parameters: 'wpName', 'wpPassword'</main> </warnings> <login result="NoName" /> </api>
The --cookie-jar option to curl only tells curl to save cookies to the jar. It doesn't tell curl to load cookies from the jar.
To get curl to load cookies from the jar you need to use the -b option to specify the cookie jar to use.