I have a fully functional perl script which talks to our SOAP webservice. Today it does that via the SOAP::Lite->service('.../name?WSDL') and then a call to execute() against the returned value. They're now locking down the WSDL so when I hit that I get a 403 error back.
I'm looking for pointers on how to change my script so that it no longer uses the WSDL to figure things out. I do have access to the WSDL itself to look at anything I need to know, but the perl script no longer will.
Since you have the WSDL file, you can use the local copy of it to drop right in with no other changes to your code:
my $soap = SOAP::Lite->service("file:localcopy.wsdl");
If you don't mind switching to SOAP::WSDL, it includes wsdl2perl.pl which will generate all of the perl packages for you:
wsdl2perl.pl file:localcopy.wsdl
Related
I want to create a custom powershell module that I can distribute without exposing the code. The script includes API calls with app specific private keys that I don't want to compromise. I've seen a lot of discussions about this over the years, but nothing that really solves my problem.
Is there a good way to create a custom powershell module without exposing the underlying code? I want to be able to distribute the powershell module, for others to import or install.
this may be what you are looking for : https://www.powershellgallery.com/packages/ps2exe/1.0.11
but be careful, the API key will still be in the compiled file at someplace. You can try and cipher it, but if it's needed for your script, it will be in your file no matter how you try to hide it. the question is why do you need to ship it inside your script in the first place ? I mean that any of your script's user will be using your private key which is likely not what you want to do
In my Scala application, I am trying to tell my KSQL Server that it should execute the RUN SCRIPT <script> command, using the KsqlRestClient.makeKsqlRequest(String ksql) function. Every time I tried it, nothing happened, even though the response was successful, so I started debugging, where I saw that the response was a success but it also returned some kind of error that the property ksql.schema.file.content was empty.
Since I did not find any documentation as to what to fill this property with, I tried some things and eventually found out that if you fill this property with the contents of your .sql file, the run script command works.
Does anybody know if and with what ksql.schema.file.content should normally be filled and/or if the way I am using it is how your supposed to execute a script in KSQL from a Scala application. I already copy and pasted the text from the makeKsqlRequest into the KSQL CLI and everything worked fine, so there should be no error with that.
There is a Github issue tracking the fact that the RESTful API is not documented / supported yet, (as of March 2018).
It sounds like this is something you may want to add a +1 too.
Is there anything like Ruby on Rails' script console for Perl's Catalyst? From rubyonrails.org:
The console command lets you interact with your Rails application from the command line. On the underside, rails console uses IRB, so if you’ve ever used it, you’ll be right at home. This is useful for testing out quick ideas with code and changing data server-side without touching the website.
I found a blog post talking about implementing it with Devel::REPL, but I cannot get it to work...
No. And, for that matter only a very small percentage of Perl users use opt for the Perl debugger at all -- this is largely because it's faster to execute and throw an exception, and because of the total transparency of Perl Objects -- they're just blessed Hashes and they serialize into strings pretty well.
I happen to like XXX, drop an
use XXX;
XXX \%hash;
or do a Catalyst::Exception->throw( YYY %v );
I've been using CatalystX::REPL with success. I'm not familiar with the RoR console but, basically, CatalystX::REPL will drop you into an interactive environment where you can inspect the application's context object and so on.
a similar question was asked in question 494120, but IMHO was not really answered...
I want to upload files to a sharepoint using perl/WebDAV (from a Win32 host). To achive this, I need to authenticate with KERBEROS on the server. After googling for hours and trying different approaches, I'm not able to open a connection. Current code is this:
my $agent = HTTP::DAV::UserAgent->new(keep_alive=>1);
$agent->agent('Agent');
$agent->timeout(1000);
my $d = HTTP::DAV->new(-useragent => $agent);
$d->credentials( -user=>$user,-pass =>$pass, -url =>$url);
$d->open( -url=>$url ) or die("Couldn't open $url: " .$d->message . "\n");
When doing the $d->open(...), I always get "Couldn't open $url: Unauthorized. Negotiate". So, obviously the basic authentication doesn't work.
Could anyone point me to the right path, please? I am not fixed to using WebDAV, any other mechanism would fit me as well. Just want to get it working...
Edit 1
When using LWP along with Authen::NTLM (as suggested by Madhur) also doesn't work. It results in a 500 internal server error on IIS as well as on Apache. Since the same error occurs on two different web servers (with two different NTLM implementations) I guess that there's gotta be a problem in the Authen::NTLM module.
Looking at the implementation of Authen::NTLM it seems to me that the code is kinda reverse engineered and neither implemented based on a specification nor is it really configurable. What turns up the question why the specification wasn't used to implement the module...
Is using NTLM along with Perl such an exotic use case?
Edit 2
Based on Madhur's suggestion, I tried accessing the Sharepoint with Curl. This works. But sniffing the NTLM messages of Curl and those sent by Perl shows me, that the message format is somehow different.
Instead of using WebDAV. I would suggest you use out of the box web services.
This gives overview on how to use sharepoint web services in PERL:
http://www.squish.net/log/2008/10/11/perl-sharepoint/
http://shareperl.blogspot.com/
And this is the .NET code to upload the file using web service:
http://www.oriolardevol.com/Article/Details/3
Converting it to PERL code is left to you as its been years since I used PERL :)
I'm very new to Perl, and I have absolutely no idea how to approach this. We have an old Perl application which previously used Apache auth; we'd like to replace this with a cookie based form-style authentication. I understand that this is very case-specific, and there is no one answer as such, but some general tips would be much appreciated.
Will I need to edit all .pl files in the website? Or is there a "golden hammer" solution I can use? Is there something on CPAN I can use? We're using Perl v5.8.8 if it matters, and we're using Apache 2 shared hosting. I am happy to provide additional information as is necessary.
For the authentication to be recognized/required, it will need to be checked by the .pl file that initially receives the user's request. So the answer to whether all .pl files will need to be changed depends on how your application is structured:
If the user goes to http://myserver.com/one.pl to do the first thing and http://myserver.com/two.pl to do the second thing, then, yes, you'll need to change them all because they're all receiving requests individually.
If the user goes to http://myserver.com/dispatch.pl?mode=one for the first thing and http://myserver.com/dispatch.pl?mode=two for the second thing and dispatch.pl calls either one.pl or two.pl behind the scenes based on the mode parameter, then you only need to change dispatch.pl, since it's the only one directly receiving requests from the user.
Edited to add: If you're dealing with the first model, then I'd strongly recommend setting up an external module (.pm file) with the cookie-handling code and calling that from each of your individual .pl files instead of duplicating that code all over the place. Ideally, this would let you get by with only a few lines of added code in each .pl:
use MyCookieHandlingModule qw(verify_cookie redirect_to_login);
my $q = CGI->new; # ...unless you're already using CGI in object-oriented mode
redirect_to_login unless verify_cookie($q);
You could do it at a level outside the Perl program.
Thanks for your answers guys, but I eventually decided on CGI::Session::Auth::DBI which works well on shared hosting.