Workflows and HTTP proxies

[David Jack Wange Olrik]

All script based workflows are unable to run if you live behind a http proxy.

 

For bash, perl, python etc. all depend upon a couple of environment variables in order to work behind a web proxy.

 

The variables are HTTP_PROXY, HTTPS_PROXY and sometimes also their lowercase variants http_proxy and https_proxy.

 

Most unix commands also use these environment variables so it would be super sweet if Alfred could set these variables before executing the workflow.

 

You can find the correct variables by calling 'networksetup' on the command line.

 

Here is a small perl script that calls networksetup in order to find the values for the environment variables:

 

    https://gist.github.com/davidolrik/6699572

 

Or you can just call:

 

    scutil --proxy

 

To get the current proxy config.

 

-- 

Best regards,

David Jack Wange Olrik

 

Edited September 25, 2013 by David Jack Wange Olrik

[Andrew]

 

All script based workflows are unable to run if you live behind a http proxy.

 

For bash, perl, python etc. all depend upon a couple of environment variables in order to work behind a web proxy.

 

The variables are HTTP_PROXY, HTTPS_PROXY and sometimes also their lowercase variants http_proxy and https_proxy.

 

Most unix commands also use these environment variables so it would be super sweet if Alfred could set these variables before executing the workflow.

 

You can find the correct variables by calling 'networksetup' on the command line.

 

Here is a small perl script that calls networksetup in order to find the values for the environment variables:

 

    https://gist.github.com/davidolrik/6699572

 

Or you can just call:

 

    scutil --proxy

 

To get the current proxy config.

 

-- 

Best regards,

David Jack Wange Olrik

 

 

 

I'm going to move this to the workflow help sub-forum to see if somebody can help find a workaround for you as Alfred, by design, doesn't import any environment or make any assumptions. This is for both performance and predictability when sharing.

 

Cheers,

Andrew

[David Jack Wange Olrik]

I'm going to move this to the workflow help sub-forum to see if somebody can help find a workaround for you as Alfred, by design, doesn't import any environment or make any assumptions. This is for both performance and predictability when sharing.

 

Cheers,

Andrew

 

I already have a workaround - albeit not a very good one.

 

This problem can be fixed in a few ways, some better than others.

 

1. Alfred reads the proxy information from the preferences, and makes this available to the Workflows through environment variables. This is the standard way of exposing the proxy to stuff that runs on the command line which the Workflows kinda are.

 

2. All Workflow authors which requires http access reads the proxy config and sets up the environment them selves.

 

3. Alfred sources the users environment, where it'll be up to the user to setup the environment variables.

 

To me solution 1 is the only viable one. Solution 2 could work but would require all current and future workflow to be updated with proxy detection code. - Solution 3 will cause problems and make stuff break as there is no way of telling what a user might have setup in their environment.

 

As to your concern about performance, you only have to read the proxy settings once when there is a change in the network.

 

Hopes this helps in finding a solution that will make workflows work behind http proxies =)

 

-- 

Best regards,

David Jack Wange Olrik

[David Jack Wange Olrik]

Alfred, by design, doesn't import any environment or make any assumptions. This is for both performance and predictability when sharing.

 

Cheers,

Andrew

 

I'm not suggesting that you import anything from the users shell environment, that would probably break a lot of things and create a bunch of unneeded support questions.

 

What I'm advocating for is that Alfred reads the proxy configuration from the System Preferences and makes that available to the Workflows.

 

-- 

Best regards,

David Jack Wange Olrik

[jdfwarrior]

 

I'm not suggesting that you import anything from the users shell environment, that would probably break a lot of things and create a bunch of unneeded support questions.

 

What I'm advocating for is that Alfred reads the proxy configuration from the System Preferences and makes that available to the Workflows.

 

-- 

Best regards,

David Jack Wange Olrik

 

 

Just as a small comment to this, you mentioned in the previous post that Alfred would only have to read the network configuration once. That isn't necessarily true. For me, I move from home (no proxy), to work (proxy), back home (no proxy) every day. Since I don't shut down my Macbook Air, Alfred wouldn't have a clue that I changed network locations or anything else unless he were continuously monitoring network configuration for changes to the current network profile or just looking for changes in IP.

 

I guess in theory your suggestion could work for desktop systems because they are more than likely going to be set up in that location, with network settings already in place and not changing. For mobile users though, it's not quite the same.

[David Jack Wange Olrik]

Just as a small comment to this, you mentioned in the previous post that Alfred would only have to read the network configuration once. That isn't necessarily true. For me, I move from home (no proxy), to work (proxy), back home (no proxy) every day. Since I don't shut down my Macbook Air, Alfred wouldn't have a clue that I changed network locations or anything else unless he were continuously monitoring network configuration for changes to the current network profile or just looking for changes in IP.

 

I too live on a laptop, that changes networks many times each day without getting shutdown. Alfred could employ a similar technique to ControlPlane (http://www.controlplaneapp.com) which more or less leaves it up to the operating system to tell it when the network changed.

 

A similar technique is available in launchd where you can make it run a specific program when the network is available. (NetworkState).

 

You could write a small script to be started as a LaunchAgent that looks at the preferences and shares this info with Alfred and then sleeps forever. Then letting launchd kill it when the network goes away, and restart it when the network comes back.

 

Obviously this is a bit of a hack, and should be done internally in Alfred via the "System Configuration Framework":

https://developer.apple.com/library/mac/documentation/Networking/Conceptual/SystemConfigFrameworks/SC_Overview/SC_Overview.html

 

 

I guess in theory your suggestion could work for desktop systems because they are more than likely going to be set up in that location, with network settings already in place and not changing. For mobile users though, it's not quite the same.

 

 

It is exactly the same for both mobile and desktop users. Turning on a VPN on a desktop would trigger a NetworkState changed "event", and the VPN might have proxies configured that all programs should use while the VPN is active.

 

-- 

Best regards,

David Jack Wange Olrik