using curl with authentication - node.js

I am running a local node.js server. I need to make a POST request with curl. It this request a user should be authenticated. So I specify user name and password in the request. The problem is that I get an error that the token cannot be found, even though login credentials are correct (I can login to the remote server directly).
curl --user username:mypassword -X POST -d '["some data"]' "http://0.0.0.0:3000/problems/problemId"
The server responses:
can not find match token bXNoYXZsb4Z1
What can be the problem? Do I use curl correctly?

There is not enough details about the server side in your question but the problem could come from the encoding of the POST data.
From the man page of curl :
-d, --data is the same as --data-ascii. To post data purely binary, you should instead use the --data-binary option. To URL-encode the value of a form field you may use --data-urlencode.
So you should try these different options.
The -X option could also be removed. From the man page :
Normally you don't need this option. All sorts of GET, HEAD, POST and PUT requests are rather invoked by using dedicated command line options.

Related

nodejs authentication token link to secure page

I started working on nodeJS token authentication and I encountered a weird issue. Is there any way I can make a link to the restricted page such that user sends Auth token to the server but without encoding it as a GET parameter in the request?
The only way I could solve it is to put the token into the session, but this solution kinda defeats the whole purpose of the token auth.
Any ideas?
Regardless of the technology (i.e. node), you want to send it as a header. In CURL, this is as simple as:
curl --header "token: ASDFASDFASJKDFLKL" http://www.example.com/protected
Depending on what you're using in node, you'll likely have a request (or req depending on how it's defined) parameter. Your header would be stored in request.headers

Authentication required error while using curl command

I am trying to use curl command , but I keep on getting Authentication required error time and again.The part of reponse is shown below :-
"Authentication Required" response (307)
I am working on a network which is behind a proxy server. So have tried to provide the proxy authentication during the request too. But have not been successfull.
Please suggest a solution.
if the URL you are trying to access is behind a login wall, you need to supply the HTTP Header "Authorization".
for example, if the server accepts basic authorization:
header=Authorization, value="Basic user:password".
replace user and password with your account credentials.
see related answer: Setting authorization using CURL
Good Luck!

Sending a request in curl via a proxy with a basic auth

How do I send a request in curl via proxy which requires basic authentication? I've skimmed through the documentation of curl and found the options -p and --proxy-basic but how exactly I could use them I couldn't figure out.
Note I don't want to apply the proxy setting system wide, I only want to send a particular request via proxy.
Found the anwser myself after some more digging:
http://curl.haxx.se/docs/manual.html states
NOTE! According to the URL specification, HTTP URLs can not contain a user and password, so that style will not work when using curl via a proxy, even though curl allows it at other times. When using a proxy, you must use the -u style for user and password.
So I was doing it the wrong way :)
Answer:
https://unix.stackexchange.com/questions/119410/using-curl-to-access-basic-auth-protected-website-via-proxy-polipo

Calling SOAP webservice using curl

I need to call a SOAP webservice using curl..
The service needs a username(user1) but does not need a password..When I execute the below, its asking for password and when I click ENTER it throws an "404" error. The same request passes successfully on SOAPUI tool.
curl -v -H "Content-Type: application/octet-stream; charset=utf-8" \
-H "SOAPAction:" \
-d #soap.csv \
-X POST https://s.net/sotest/FileAttachmentService?wsdl \
-u user1
curl's -u parameter specifies the user/password for HTTP authentication.
All HTTP authentication schemes have a userid and a password, of some kind.
Your claim that you only need to provide a username suggests that username is really a parameter of your SOAP call, rather than used for HTTP authentication.
Another potential problem I can see is that SOAP is really just XML over HTTP, and most SOAP services typically use either text/xml or application/xml MIME content type, rather than application/octet-stream.
So, talk to whoever runs your SOAP service. Find out whether you are expected to use HTTP authentication or include a username parameter in your SOAP request, as well as the MIME type of your SOAP request.
I dont think that the problem is related to the user/pass as you'd get a 403 (permision denied) and not a 404 (not found) in case there is something wrong with the authentication information. It must be related to the URL. Are you sure that the complete URL is correct? You should take the "?wsdl" out of the URL-path, because this points to the location of the WSDL and not to the Webservice endpoint.

passport.js local strategy- logging in with username, authenticate later requests with token

I'm having trouble with passport.js using the local strategy. I have 2 specific problems:
I am not getting persistent sessions to work with example code (see
below) for the most basic case.
I want to go sessionless. For the
most basic case, on login, I'll pass in a username + password that
provides me with a session token, on regular requests I'll use this
session token hashed with some other stuff to authenticate. Is this
easily done with passport? It seems like passport doesn't offer much in this case and that cooking up my own solution is easier- just login/logout with standard checks, and then a middleware that unhashes request tokens to verify requests. Easy cheezy?
Problem 1:
Using the reference code from the library:
https://github.com/jaredhanson/passport-local/blob/master/examples/login/app.js
I do a series of commands to show logged out vs logged in:
A. check /account, not logged in
curl -v localhost:3000/account
As expected I get a redirect to /login
<p>Moved Temporarily. Redirecting to http://localhost:3000/login</p>
B. login
curl -v -d "username=bob&password=secret" http://127.0.0.1:3000/login
Also as expected, I get a redirect to /
<p>Moved Temporarily. Redirecting to http://127.0.0.1:3000/</p>
C. check /account, logged in
curl -v localhost:3000/account
What the hell???
<p>Moved Temporarily. Redirecting to http://localhost:3000/login</p>
In the case of 1, session support requires cookies to be configured on your server side and used by your user agent. Typically this is a browser, which will will transmit the cookies in each request, and the server uses them to restore your login state.
However, the curl commands you are using won't transmit cookies, so each request looks "new" to the server, which is why you see the redirect to login each time. I suspect if you try the same requests in a browser, this will work as expected.
As for 2, I'd need a few more details to suggest a good solution. If you are using HTML and web browsers to access your site, you're going to end up needing something like sessions. You could transmit this info in query parameters each time, rather than cookies, but you'll end up rebuilding a lot of what Express/Connect provides out of the box.
In any case, if you choose to go down that route, Passport provides a clean interface to implement your own authentication strategies. You'll simply need to parse the request for the relevant credentials and look up a user in your database.
API clients are different, and I'd suggest taking a look at Passport's OAuth support, which provides easy ways to authenticate access tokens that are associated with a specific client.
The problem isn't with passport, the curl command needs to store the cookie, so -c and -b parameters should be used to mimic browser behaviour. From curl manpage:
curl -b cookies.txt -c cookies.txt www.example.com
What this command does, is to store cookies in cookies.txt and send cookies reading them from cookies.txt - This is the way curl mimics netscape cookie-jar file format to write and read from.
As for your question per-se, Jared has already answered it!

Resources