Makina-Corpus.Org

SQLAlchemy (The Python SQL Toolkit and Object Relational Mapper) allow Oracle connection through the cx_oracle driver. This how-to describes how to install SQLAlchemy for Oracle Database and how to integrate it in buildout and use it in a browser view.

If you develop a web application you’ll come soon at the moment of building your URLs.

The best thing to do, either, is handling relative URL. If your app can behave with relative URL and handle a base_url prefix for sites installed in sub-directories (like ‘/myapp/is/here/’) you’ll be friend with sysadmins. — if you use Zend Framework have a look at the setBaseUrl() router function–

But most app do not handle URL this way, and absolute urls are used, sad world. Then you’ll find theses URL in HTML content, in css, in javascript, and every object generated by your web application. That’s hell for admins.

First moving your app on a different domain will maybe be harder (especially if you’re a bad coder and this absolute URL is not writed once in a config file).

Then serving your app with different domains in the same time won’t be possible.

And harder, you’ll break proxy rewriting.

The job of the proxy is to serve your web application on a different namespace. Maybe you have a myapp.localnetwork.net application, that every people in localnetwork.net will see. The proxy will server myapp.publicdomain.com or even publicdomain.com/myapp/is/here. And the job of the proxy is only handling HTTP headers. That means he will only rewrite things like redirect (which is a code and url in headers of the response, not in the HTTP content.

browser
    \->myapp.publicdomain.com (proxy)
                \->myapp.anotherproxy.domain.com (proxy)
                      \->myapp.localnetwork.net

So you’ll maybe ask the proxy maintainer to rewrite things on the content as well. ok, this can be done with mod_proxy_html for example in apache. But this as 2 drawbacks: this module is parsing every content and rewriting it, that’s really slower. And this module cannot handle all content, he will maybe forget one of your unknow localmnetwork.net url in a javascript file… big bugs.

So… if you either use absolute_url, then you should test if any proxy is between you and the guy requesting the page. This is given by Apache to PHP in the HTTP_X_FORWARDED_HOST parameter (or something similar if you’re not in PHP, that means it’s something your webserver knows by HTTP headers of the request). There you’ll find a list of proxy used (if any) between you and the browser. Be carefull, it’s a coma separated list, with spaces. The name you should use as the base name of your site is the first name of this list.
In our example we’ll have: “myapp.publicdomain.com, myapp.anotherproxy.domain.com”and your absolute url to use is http://myapp.publicdomain.com

With that name overriding your default base name you’ll have a better app. But the problem is not really completly fixed in fact. What you have is the host name, but you do not have any information about the protocol. Maybe you’ll prefix the name with ‘http://’ and it will be ok, but maybe the proxy is using ssl (because using ssl for a public filtering proxy before intranet application is something used a lot). And the protocol should be ‘https://’. If you decide to handle this in a config file of you application you’ll obtain ‘https://’ even in your local network, where you should’nt. Your only solution will be to tell your app which protocol to use for which name. Quite dirty.
Well, in fact there’s a solution, the proxy can set:

RequestHeader set X-Forwarded-Proto "https"

On his SSL configuration and you’ll have HTTP_X_FORWARDED_PROTO available on your code.

All theses things works because of ‘de facto’ http headers added by mod_proxy on Apache. You’ll maybe wont have them, and your application will rely on proxy configuration. Remember relative URL is still the best solution.

I dont know how much people get to this problem, but one thing is sure: when you have a paranoid sysadmin, you might encounter some surprises with PHP and globals.

The annoying case is here when you restrict PHP to the maximum you can, you can't access to the $_REQUEST superglobal.
<!--break-->
FYI1, this superglobal is an array merge (copius vulgaris2) of both $_POST and $_GET superglobals..

What's saves us is that in Drupal's core code, this $_REQUEST superglobal is never used (or was sometimes ago), some grep3 revealed it to me.

But, what's annoying here, is the only part of Drupal I found usage of this variable, is the update.php file. So, what happens in real life, when you try to update you site in this case?
The answer is: "Just nothing.".

Why? Because update.php can't find it's op parameter, which, in facts, comes directly from $_GET or $_POST (depending on the step you are).

So, the actual solution, is this patch (working for Drupal 6.12):

WTF does this patch4 do?!
Simple, it handles the original developer lazyness, just does a simple test which is, "Do I have my $_POST['op'] parameter? Yes? Ok, use it!" Simple hu?

One line of code, some hours of happyness saved!

1. 1. FYI, FYI means "For You Information"
2. 2. Which in some case, is wrong; this is a copy of those superglobals, so if you aptempt to modify a value in $_REQUEST, it won't modify the original value got in $_GET or $_POST
3. 3. May UNIX be with you
4. 4. To use it, by the way, download the attached file, and simply use the "patch" command of your OS (RTFM, please)

Attachment	Size
update.php-6.12-request_bug.patch	345 bytes