I am writing a perl script that should login to Gowalla, fetch some information and check in. Looking at the http://api.gowalla.com/api/docs I don't find a way to "login". It seems they want every request to include the username and the password.
I thought it should be possible to first "login" and then use the supplied cookie to keep the conversation.
Am I missing something there or is that the case?
It says they use Basic Authentication. If you are using the LWP type of thing:
my $req = HTTP::Request->new( POST => 'http://somesite.com/');
$req->authorization_basic('username', 'password');
# using data supplied by the other answer.
$req->header( 'X-Gowalla-API-Key' => 'YOURKEY' );
my $resp = $ua->request($req);
Their API simply does not allow what you ask for. Quoting,
All authentication is handled with HTTP Basic Authentication. All
calls must also include your
Gowalla API Key in a X-Gowalla-API-Key
request header.
Nowhere in the document is mentioned "cookie", either.
So every time you want to make a request to them, you must supply both the HTTP basic auth info, and the X-Gowalla_API-Key HTTP header.
Related
The HTTP Request I used to send to a specific website is now getting redirected which eventually broke my code. I realized that the cookies are not working anymore for the redirected domain (of course). I read the docs of LWP but I did not find any related option to preserve/maintain cookies automatically. Is there an easy way to do it?
Just for a side note: this behavior works out of the box using Python's Requests class.
The following adds support for cookies to LWP::UserAgent.
my $ua = LWP::UserAgent->new( cookie_jar => {} );
It causes cookies returned in a response to be sent with subsequent matching requests, just like a browser does.
How can I attach an image to an existing Confluence page, using their latest REST API, from Perl via the REST::Client module?
This may be a perl question (I may be posting an image incorrectly), or a Confluence question (their API docs may be missing a required detail such as a required header that is being quietly added by curl), or both.
I have established a connection object, $client, using the REST::Client module. I have verified that $client is a valid connection by performing a $client->GET to a known Confluence page ID, which correctly returns the page's details.
I attempt to upload an image, using:
$headers = {Accept => 'application/json',
Authorization => 'Basic ' . encode_base64($user . ':' .
$password),
X_Atlassian_Token => 'no-check',
Content_Type => 'form-data',
Content =>
[ file => ["file1.jpg"], ]};
$client->POST('rest/api/content/44073843/child/attachment', $headers);
... and the image doesn't appear on the attachments list.
I've packet-sniffed the browser whilst uploading an image there, only to find that it uses the prototype API that is being deprecated. I'd hoped that I could just stand on Atlassian's shoulders in terms of seeing exactly what their post stream looks like, and replicating that... but I don't want to use the API that's being deprecated, since they recommend against it.
The curl example of calling the Confluence API to attach a file that they give at https://developer.atlassian.com/confdev/confluence-rest-api/confluence-rest-api-examples, when my host, filename, and page ID are substituted in, does post the attachment.
I formerly specified comment in my array of Content items, but removed that during debugging to simplify things since the documentation said it was optional.
One thing I'm unclear about is getting the contents of the file into the post stream. In the curl command, the # accomplishes that. In REST::Client, I'm not sure if I have to do something more than I did, to make that happen.
I can't packet-sniff the outgoing traffic because our server only allows https, and I don't know how (or if it's even possible) to set the REST::Client module or one of its underlying modules to record the SSL info to a log file so that Wireshark can pick it up and decode the resulting TLS traffic, the way one can with the environment variable for Chrome or Firefox. I also don't have access to server logs. So I don't know what the request I'm actually sending looks like (if I did, I could probably say, "OK, it looks wrong right HERE" or "But it looks right?!"). I am therefore unfortunately at a loss as to how to debug it so blindly.
A similar question about posting multipart forms using REST::Client was asked by someone else, more generically, back in April of last year, but received no responses. I'm hoping that since mine is more specific, someone can tell me what I might be doing wrong.
Any help would be appreciated.
You should be capturing your post response like so:
my $response = $client->POST('rest/api/content/44073843/child/attachment', $headers); print Dumper $response;
Also, the url you are using in the POST call is incomplete and won't work, you need the full url.
I am sending a PERL POST Request over HTTPS. During sending the request i need to send two things in content one is an authorization token and other is the command need to be executed on the server side.
What should be the approach to send these two things as the content?
Should it be:-
$request->content($token)
$request->content($command)
OR should it be
my #content =($token,$command)
$request->content(\#content)
The module which i am using is LWP::UserAgent and in that i will be creating a HTTP::Request type object my $request = HTTP::Request->new(POST => "<url>"); and in
this object i am sending content.
There is only a single content (request body) for a POST request. So any call of content just replaces the previously defined content. Please have a look at the documentation for LWP::UserAgent::post which clearly defines how to send POST data with multiple values. Also, it might be useful if you understand how forms in HTML work, both on the client (browser) and on the server side. Because only if you know what the server side expects in detail you can create the proper request.
My work requires an authorization for internet use. I log in, and after that it recognizes me and lets me access whatever I need.
I have been using POSTMAN to test send to and receive from a company RESTful service. It automatically uses my same internet use auth at the other end to give my user account POST and GET permissions.
Now, I am trying to automate with a perl script and it won't authorize. The owner of the RESTful service says if I make a windows/.net application it will authorize automatically, but that isn't an option.
Any suggestions? I would think I could just do special headers or something and duplicate whatever windows is doing....
I have been asked to provide what I have done so far
#!/usr/local/bin/perl
use strict;
use LWP::UserAgent;
my $ua=LWP::UserAgent->new;
my $server_endpoint = "The post destination";
my $req= HTTP::Request->new(POST => $server_endpoint);
$req->header('content-type' => 'application/json');
my $post_data="[ SOME JSON HERE ]";
$req->content($post_data);
my $resp = $ua->request($req);
if($resp->is_success){
my $message = $resp->decoded_content;
print "received reply : $message\n";
}
else{
print "post error code : ",$resp->code,"\n";
print "post error message : ",$resp->message,"\n";
}
In the past when I had to authenticate against an IIS server I had to use LWP::Authen::Ntlm to get it to authenticate.
For more information about LWP::Authen::Ntlm, see https://metacpan.org/pod/LWP::Authen::Ntlm
The main "pitfalls" I had is that keepalive is required, and that newer versions of IIS now use Digest, and not NTLM
In those cases, I simply switched to the built-in LWP::Authen::Digest (it comes inside LWP)
Have a look at a similar question (scroll up to the top see the question) and see if the included bit of Perl code doesn't help...
LWP::UserAgent HTTP Basic Authentication
The short version is that it doesn't appear that your Perl code above includes any login information and this POSTMAN plugin may be sending over cached login info that your Perl code is not yet aware of.
We received a request to create a REST api. I was a little confused in the example of provided by our client. As you can see below, they've identified the app_id and secret in the URL before the #. The remainder of the URI looks like what I would expect.
Is this valid? I thought maybe this is some weird cURL format I haven't seen before.
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/entity_locations/{locations_id}/
Just seeing if anyone has seen this format before?
A URI is made up of various parts, one of them being the authority part, which can feature optional username:password element.
The full scheme is:
scheme://username:password#domain:port/path?query_string#fragment_id
This way your REST api remains stateless [not relying on previous app states like storing stuff in session]. But I advice you not to explicitly go with the username:password#stuff route, but to rely on Basic HTTP Auth, so the credentials are sent encoded in Base64 at least.
EDIT: a brief note about BasicAuth now you're asking - things go like this:
you make a request to http://johndoe:12345#service/api/foo/bar;
are credentials good? Ok, you get a 200 OK response with proper body;
are they not? You get a 401 Unauthorized response.
In the latter case, it's the browser [or any other program / script performing the request] that should prompt the user with the login popup.
Usually browsers ask you to cache credentials not to ask them every time, but this does not mean that they are not sent - it's just that every request to protected resources are featured with such header:
Authorization Basic base64encode(username:password)
Where base64encode is your custom way to encode the username:password string.