perl jira rest api port number-CodePudding

my $jira = JIRA::REST->new({
    url      => 'https://something.com:8443',
    username => 'username',
    password => 'password',
    session  => 1,
});

The above code doesn't work and fails with below error probably due to port number at the end

Can't connect to something.com:8443 (Bad file descriptor)

is there a way/variable to mention the port number?

CodePudding user response：

You need to add the setting ssl_verify_none => 1 into the hash used in your constructor.

The underlying LWP code allows you to not verify the certs of systems you connect to (which is not recommended for production), or it also allows you to specify a Certificate Authority (CA) cert that can be used to verify certs of systems you connect to. It looks like JIRA::REST has only supported the first option.

You might be better off just using the underlying LWP code, like this:

use LWP::UserAgent;

my $ua = LWP::UserAgent->new(
    ssl_opts => { verify_hostname => 1, SSL_ca_file  => 'myCA.cer' },
    protocols_allowed => ['https'],
);

my $req = HTTP::Request->new( 
    GET => 'https://something.com:8443/rest/api/latest/issue/ABC-123',
);
$req->authorization_basic('username','password');
my $res = $ua->request($req);

It looks like JIRA::REST is just providing the raw JSON response to you anyway, so it's not really saving you all that much processing.

CodePudding user response：

The main advantage of REST::Client is that it saves some stuff for you to add to each request implicitly. There's nothing particularly REST-y or helpful beyond sending a request and giving its response back to you. The JIRA::Client has a few advantages, though, since it knows how to get a session cookie and properly attach files, and, more importantly, deal with paginated results. But often, when I'm doing things with Jira, I want more power.

Back in LWP's heyday, it was very frustrating to track transactions: a request-response pair. You could, but you had to manage it yourself. And, there weren't hooks in the process, so you had to create everything every time.

Then, LWP tried to work around some SSL issues (verifying host names, etc) and also split out LWP::Protocol::https. That's not a big deal when you understand that, but even though I do, it's something I have to remember every time I want to use LWP for something. There are reasons for everything that happened, but that doesn't make it any less annoying. That leads to the sort of work jimtut showed in his answer. Every time. But, it's a small speed bump on the way to insecurity.

I like Mojolicious much more because it represents complete transactions but also has hooks (well, events) that allow you to fiddle with things automatically while the process is chugging along.

Here's an example from Mojo Web Clients that shows me creating a user-agent for each service and setting some stuff for each transaction. I can adjust the request any way that I please before it does its work (and this is mostly what that REST::Client and JIRA::Client are doing for you):

my $travis_ua = Mojo::UserAgent->new();
$travis_ua->on( start => sub {
    my( $ua, $tx ) = @_;
    $tx->req->headers->authorization(
      "token $ENV{TRAVIS_API_KEY}" );
    $tx->req->headers->accept(
      'application/vnd.travis-ci.2.1 json' );
    } );

my $appveyor_ua = Mojo::UserAgent->new();
$appveyor_ua->on( start => sub {
    my( $ua, $tx ) = @_;
    $tx->req->headers->authorization(
            "Bearer $ENV{APPVEYOR_API_KEY}" );
    } );

In the Basic auth case, it's just a different value in that header:

use Mojo::Util qw(b64_encode);

my $jira_ua = Mojo::UserAgent->new();
$jira_ua->on( start => sub {
    my( $ua, $tx ) = @_;
    $tx->req->headers->authorization(
            'Basic ' . b64_encode( join ':', $username, $password ) );
    } );

Now, when I use those user-agents, the auth stuff is automatically added:

my $tx = $travis_ua->get( $url );

And, that $tx gives me access to the request and the response, so I don't need REST::Client to handle that for me either.

Since Mojolicious is handling all of this in one convenient package, I don't have to wrangle different objects. As such, there's not much left over that REST::Client can do for me.