Hello:

One web site I manage is hosted behind a firewalled subnet which is not allowed to access most sites, including Gary Keith's page with the latest browscap.ini files. Assuming I can't persuade the firewall administrators to allow an exception (I tried before), I would like to know if there is a good way to update the data manually. I realize that one purpose for creating this module was to eliminate the need to manually update browscap.ini files, but is there a better way for us to manually update browscap's data, since we use other modules/themes that rely on it? I temporarily took our web server offline and connected it to a less restrictive network to grab the update (which solved the problem I was having), and then put the server back on the proper network.

I assume that I might be able to use one of the following methods for updates:

1) Manually upload the version and INI files to my web server and change the source directories to localhost for $versionpage and $browscap in the module.
2) Update a development server which has connectivity, dump its browscap MySQL table and restore the table on the production server (Is that sufficient or is there more to it?)
3) Hack the module to attempt to check a fixed file location (perhaps in the site's "files" directory) as well as checking online.
4) Add some cool feature to the module to allow pointing to a local file or even uploading or pasting the proper file from an admin page...

I saw a somewhat-related post in the issue queue to allow updating from an alternate server. This seems like related functionality to me.

Thanks.

Comments

computerwill’s picture

computerwill commented

FYI: In case anyone else is trying to work around this, here's what I did. I modified the URLs in browscap.module around lines 313 and 337 tp point to locally hosted files. I wget the original files from a normal workstation, and sftp them to the production server. I put them in my Drupal files directory. After that, I go to the browscap admin page and click the "Refresh now" link to complete the process.

Example:

$versionpage = drupal_http_request('http://localhost/files/support/browscap/version-number.asp');
...
$browscap = drupal_http_request('http://localhost/files/support/browscap/stream.asp@PHP_BrowsCapINI');
Then from a workstation:

wget http://browsers.garykeith.com/versions/version-number.asp 
wget http://browsers.garykeith.com/stream.asp?PHP_BrowsCapINI

... then I copy the files to my web server in the appropriate directory and refresh browscap as described earlier.

devin carlson’s picture

devin carlson commented
Title: Offline / manual updates for firewalled production servers » Provide a method for manually updating the browscap information
Version: 6.x-1.1 » 7.x-1.x-dev
Component: Miscellaneous » User interface

Marked #1013788: Provide form to upload browscap file manually as a duplicate and updated the issue title.

shane birley’s picture

shane birley commented

Throwing in my two cents. I am playing with Mobile Tools and am testing out browscap.module and ran into this problem. This isn't ideal but it works for now.

Download Static Versions of Browscap Files

  1. Download http://browsers.garykeith.com/stream.asp?PHP_BrowsCapINI
  2. Download http://browsers.garykeith.com/versions/version-number.asp
  3. Save .ini file as php_browscap.ini
  4. Save the version-number.asp as version-number.htm
  5. Created a sub-folder in the site /files directory called /browscap and uploaded the files into that directory.

Cracked open import.inc

  1. Change line 18: to $current_version = drupal_http_request('http://www.example.com/sites/default/files/browscap/version-number.htm');
  2. Change line 51: to $browscap_data = drupal_http_request('http://www.example.com/sites/default/files/browscap/php_browscap.ini');

Of course, you can place the files where you want, just so that they are available. This appears to work fine. I suspect that this process could be automated?

NOTE: I did this for version Drupal 6.x and not Drupal 7.x but I would imagine the issue is the same.

gianfrasoft’s picture

gianfrasoft commented

Manually upload of the INI files would be great!

gianfrasoft’s picture

gianfrasoft commented
Priority: Normal » Major
computerwill’s picture

computerwill commented
Title: Provide a method for manually updating the browscap information » Provide a method for manually updating the browscap information [WORKAROUND]

OK, I had to revisit this after the latest update. I had previously used a solution similar to Shane's comment (http://drupal.org/node/749498#comment-5620634). The URL changed in a recent version, and I kept thinking that there had to be a better way. I do not recommend this method that I am about to describe, but it worked for me, and it may help some other poor soul trapped behind an over-aggressive firewall policy. To make this work the same way, you will need to be able to connect to your server with a remote SSH tunnel, have the ability to edit the system's host file, and make minor edits to the import.inc file. The assumption is that your SSH client's workstation does have proper access to the URL. Once you implement this change, future updates are simpler than manually uploading the files somewhere else.

My platform: Debian Linux 6, Drupal 6, browscap 6.x-2.0 on a web server that is not allowed to make http connections due to external firewall rules. I see no reason why this wouldn't work on other flavors of Linux, or even Windows.

Modify browscap

  • Backup the import.inc file from the browscap module.
  • Modify the import.inc file at the drupal_http_request lines, adding a port number that is unused by the server (I used 889). At the time of this writing, the URL points to tempdownloads.browserscap.com. If this has since changed, hopefully you can adjust accordingly. The changes are near lines 18 and 51 in my version:
    #$browscap_data = drupal_http_request('http://tempdownloads.browserscap.com/stream.php?BrowsCapINI');
$browscap_data = drupal_http_request('http://tempdownloads.browserscap.com:889/stream.php?BrowsCapINI');

    and

    #$current_version = drupal_http_request('http://tempdownloads.browserscap.com/versions/version-number.php');
$current_version = drupal_http_request('http://tempdownloads.browserscap.com:889/versions/version-number.php');

Hosts file modification
I tried doing this sensibly by using localhost, but that didn't work, probably due to the remote web server having no clue which virtual server to route my request to. This will make more sense if you keep reading. So, I modified the servers /etc/hosts file (or perhaps c:\windows\system32\drivers\etc\hosts on Windows), and added an alias of tempdownloads.browserscap.com to the end of the entry for 127.0.0.1. Also note, that it had to be 127.0.0.1. It didn't like it when I tried to use another 127.0.0.x address. Here is a sample entry:
127.0.0.1 localhost tempdownloads.browserscap.com

Now to tie all this insanity together:

SSH configuration:
I use PuTTY, but any decent SSH client should be able to do this, assuming it isn't blocked by the server.

  • Modify your SSH session to allow a remote tunnel to the port number you used earlier. In OpenSSH, you can do this with the "-R" option on your command line. I mapped a remote (not local) tunnel from port 889 to tempdownloads.browserscap.com on port 80.

Use it!
Now, open your newly modified SSH session to your server. If you enable debugging or view your PuTTY event log, you can watch the magic. Once you have established a session, open your web browser and go to the browscap administration page. When you request a manual update, Drupal thinks it's contacting tempdownloads.browserscap.com on port 889, but it is really being tunneled through to tempdownloads.browserscap.com via your SSH client workstation. For me, the update works, and it grabs a new version. Please note that if you have automatic browscap updates enabled, then you will need to find a way to keep this tunnel open, or it breaks. I just initiate it manually.

Good luck!

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Active » Closed (duplicate)

There's an issue at #1788720: Allow to change the URLs to use for importing useragent information with a patch that seems like it would fix this issue, so marking this as a duplicate of that.