Downloading SetupTools in Maximo/Jython fails with HTTP error 403 SSL is required - ssl

Appendix A of The Definitive Guide to Jython describes downloading SetupTools for use with Jython.
https://jython.readthedocs.io/en/latest/appendixA/
This indicates to me that it should be possible to download and use SetupTools from within a Jython automation script in Maximo (v7.6 in my case). The book points us to the following url to copy a Jython script that will do this:
http://peak.telecommunity.com/dist/ez_setup.py
I add one line to the above script to call the function "use_setuptools":
use_setuptools()
Then I create a push button on a Maximo application and associate the aforementioned script with the button press I get the following error:
System Message BMXAA7837E - An error occured that prevented the
EZ_SETUP script for the EZ_SETUP launch point from running.
urllib2.HTTPError: HTTP Error 403: SSL is required in at line
number 280
The stack trace points to the following line in the function "download_setuptools" which is called by "use_setuptools":
src = urllib2.urlopen(url)
This appears to be because the url requested, in my case:
http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c11-py2.5.egg
...is redirected a few times before arriving at the following url:
https://files.pythonhosted.org/packages/98/d3/ed3bc7e3f4b143092862dab99d984261ac4be6a40d4fb1e66d2a10e9ea99/setuptools-0.6c11-py2.5.egg
Note the url uses HTTPS not HTTP. The following indicates why this may be so:
https://sourceforge.net/p/pypi/support-requests/300/
The jython.jar included with Maximo does not include the ssl module so we could either:
Download the ssl module manually and copy it to the correct location on the server.
Download the appropriate egg file manually over HTTPS and copy it to the correct location on the server.
Bypass the problem by creating a mirror for the file we're looking for that is accessible over HTTP and use that url in the code.
Whilst these are feasible I'd prefer to modify the code to ignore the SSL certificate if possible, however all the workarounds on StackOverflow and elsewhere seem to require that you're able to "import ssl" in order to bypass it which rather seems to defeat the purpose.
Ideally I'm looking for a solution that modifies the code from the url provided above to get it to work with Maximo/Jython 2.5.2 and doesn't require downloading and adding new modules or packages and all that this entails with Maximo. Bypassing or temporarily disabling ssl is fine as the code checks the hash of the downloaded .egg file. This would be my preferred solution if possible.

In my experience, automation scripting works best if you can stay "as Java as possible" and "as Maximo as possible". So, I would use the LIB_HTTPCLIENT script from the Scripting 76 Features document (the first example code, whose name is given by inference in the second bit of code) to try to download the SetupTools.
In case that document moves again, here is the LIB_HTTPCLIENT script. Note that the url variable is expected to be passed to this library script by the calling script.
from psdi.iface.router import HTTPHandler
from java.util import HashMap
from java.util import String
handler = HTTPHandler()
map = HashMap()
map.put("URL",url)
map.put("HTTPMETHOD","GET")
responseBytes = handler.invoke(map,None)
response = String(responseBytes,"utf-8")

Related

apache seems to ignore "Internal Server Error" returned by CGI script

I'm writing a Python CGI script and trying to test the behaviour of the system when I need to return Status: 500 Internal Server Error.
My script is something like that:
#!/usr/bin/env python3
print("Content-type: text/html")
print("Status: 500 Internal Server Error")
print()
When I run this script there is a report in apache access log with code 500, but it's not reported in the error log. I also don't get a "500 page" in the browser.
If an internal error is caused by some other means (e.g., a script that is not executable, or contains bad HTTP header) I do get the "normal" behaviour of internal server error.
It seems like apache is ignoring, somehow, the status returned from (my) CGI scripts. I've searched for an answer but couldn't find anything.
Just for clarity, CGI is working fine on this server in any other aspect.
Any thoughts? Am I missing something?
Thansk,
Amit
Answering to myself: it seems that I was barking up the wrong tree. Based on some clues and more empirical results, It seems that when passing a request to an external script (e.g. a cgi script, php etc) the apache server expects the external script to handle any error, and it's the responsibility of the external script's to return a document that includes the error code and an error message. The external script is also responsible to log the error (it's usually enough to print it to the standard error, and it'll be picked by apache and be written to its error log).
So, for example, if my cgi script needs to report an "Internal Server Error" it is not enough to return just the header (see in my question), but it should create and return the whole error message, in HTML format. In addition, it should print an error message to the standard error.
I haven't found an official source for that, but perhaps I somehow overlooked it.

Calling Cpanel UAPI method

i have the following simple script to list the ftp accounts
but i am unable to get it to work as i have the following error as soon as it tries to call the constructor
include '/usr/local/cpanel/php/cpanel.php';
$cpanel = new CPANEL(); // Connect to cPanel - only do this once.
// List FTP account information.
$list_ftp_accts = $cpanel->uapi('Ftp', 'list_ftp');
echo "<pre>";
print_r($list_ftp_accts);
Fatal error: Uncaught exception 'RuntimeException' with message 'There
was a problem fetching the env variable containing the path to the
socket' in /usr/local/cpanel/php/cpanel.php:146 Stack trace: #0
/public_html/uapi.php(4): CPANEL->__construct() #1
{main} thrown in /usr/local/cpanel/php/cpanel.php on line 146
Line 146 in cpanel.php
$socketfile = getenv('CPANEL_PHPCONNECT_SOCKET');
According to a post on the cPanel forums, you can only use LiveAPI from within cPanel's document root, meaning your code would need to be in either /usr/local/cpanel/base/frontend/ or /usr/local/cpanel/base/3rdparty/. I ran into this while trying to use it in a WHM plugin (which would reside in /usr/local/cpanel/whostmgr/docroot/), and apparently that causes the same problem. If you're trying to run this from within cPanel or WHM, this page has some debugging steps you can try walking through.
If you're trying to run this code on a different server or from within a normal website's hosting account, you'll definitely need to use a different interface, such as the XML or JSON API. These are unfortunately somewhat confusingly documented, but the Guide to WHM API 1 page should get you started.
Me too got the same error.
Try changing your file extension to your_file.live.php, instead of your_file.php. It solved the issue for me.
Referred the documentation here.

Can't disable WSGIErrorOverride

I am backing a web app with a Flask API that returns custom error codes. The API runs through Apache and the WSGI module, in daemon mode.
I included a WSGIErrorOverride Off instruction in the Apache conf file for the API (which is supposed to be the default but I included it anyway).
Yet anytime my Flask app returns a custom error code (they work when I run the app using the built-in server), Apache sends an error 500. How can I prevent that?
Thanks to comments by duskwuff and Graham Dumpleton, I found that the problem doesn't come from Apache WSGI but from my Flask app.
More precisely, I was using the Flask-RESTful package, which is in charge, among other things, of transforming my views' return values into actual responses.
When those views are decorated (here with an equivalent of #login_required), those decorators are called by the Flask-RESTful package itself, and when an exception is thrown, something goes wrong.
For some reason, my app returns the custom error when I run the built-in server and an error 500 when I run it over Apache. Not quite sure why yet, I'm guessing Flask-RESTful is doing something that is not WSGI-compliant. I was on the verge of dropping it anyway for other reasons, so I'm OK with this solution.
Update: it looks like the problem does indeed come from Flask-RESTful: https://github.com/flask-restful/flask-restful/issues/372

Sporadic invalid_request 400 errors connecting to Shopify /admin/oauth/access_token

I am using a java raw HTTP client to connect to Shopify API (specifically, using Play Framework with the non-defualt sync driver which is actually the JDK's default driver).
My application usually manages to connect successfully and convert the temporary access token into a permanent one by calling the /admin/oauth/access_token endpoint.
However, sometimes I get this error result from the API:
Generic Error(400)
{"error":"invalid_request"}
I haven't been able to reproduce the issue with my test stores - I've tried installing a fresh store, reinstalling existing stores after uninstalling, I'm not sure why this call sometimes fail and how to debug it. The API call still continues to succeed for some stores using our application.
Some things that I am doing:
Even if the URL of the store is on a custom domain, I'm always using the https://foo.myshopfiy.com/admin/oauth/access_token URL and not the URL of the custom domain, to prevent a redirect.
I am always using an https URL and never an http one, again to prevent a redirect (we noticed a few issues with redirect with the Java HTTP client, so we aim to have zero redirects)
A thread I found about this error suggest possible problems with our SSL certificates, however I don't think this is my problem because some requests work for us, and the result of running openssl on our machine does't show any issues.
How should I proceed? Open a support ticket with Shopify?
FYI, I see that this specific problem only started yesterday on Feb 19 2013, so it might be a temporary issue.
FYI, the problem was caused by reusing a temporary access code.
Our fault - Shopify could have been more clear in their error message though.

Thread: 505.50 when using custom rewrite provider (the one from samples)

I'd like to know how to troubleshoot IIS URL Rewrite module and custom rewrite providers?
I am trying to do a POC on the URL Rewrite Module for our app. Our mappings are all in the database so I thought using the provider that comes as a sample. Got everything installed and configured, as instructed. Created the stored procedure as well. Now when I hit the alias URL I receive HTTP Error 500.50 - URL Rewrite Module Error. Here are the details about the error:
Module RewriteModule
Notification BeginRequest
Handler ExtensionlessUrlHandler-Integrated-4.0
Error Code 0x80070585
In SQL Profiler I see no calls to my stored procedure. The app pool is running under my account (admin rights). No errors in the event logs.
Are there any logs I could look into for more information on what's happening?
I got it working after two days of digging. The samples are good but not good enough: simply using supplied DLLs with supplied config entries doesn't work (for many reasons).
What I ended up doing was getting rid of the DLLs from samples and creating my own provider using the source code from samples and information from this article: Developing a Custom Rewrite Provider for URL Rewrite Module. Then IIS started loading my provider. But in order to make it work correctly I had to get deep understanding of module's config system.
So my answer to my own question -- don't relay on samples alone, they don't work out of the box. Instead, RTFM :) The best place to start is here: URL Rewrite Module Configuration Reference