David Jack Wange Olrik

Fair enough! I'll get that fixed up for the next release

Excellent! - Maybe add the prefix to Alfreds preference plist for both http and https, so a "power" user can do a "defaults write" to change it from http to https if needed.

for now, have you prefixed http:// to OS X's setup for the proxies? this will likely be passed through and Alfred will work

I tried that, and it works for Alfred - but it breaks Safari and other "normal" applications that use http/https.

Interesting, I wasn't aware of this. As I don't want Alfred to be discovering the proxies, I may add an option along side the proxy option to say prefix http if missing.

Alfred wouldn't be discovering the proxy, just checking to see if it's http or https - but your proposed solution would work for me =)

Hi,

A lot of workflows are not working when being used behind a proxy.

After some debugging it seems that you are just passing the proxy value from the system preferences, alas this will not work with a lot of languages and programs as the correct format for the http_proxy and https_proxy environment variables includes the protocol like so:

http_proxy=http://username:password@proxy:port
https_proxy=http://username:password@proxy:port

And for the system proxy to work, only an ip or a hostname can be specified.

I don't know of any way that you can obtain the correct protocol prefix from the system.

Prefixing with http:// should work in most(but not all) cases as most proxies are run on a non secure port.

If you can't find a way to get the prefix from the system, then you have to connect to the proxy and detect it there.

-- 
Best regards,
David Jack Wange Olrik <david@olrik.dk>       http://david.olrik.dk
GnuPG fingerprint 4171 FCB3 EE86 6A03 B436 5AED 5F41 087D 7AB1 A4B5
["The first rule of Perl club is  You do not talk about Perl club"]

Using v2.5.1 (308)

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.

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.

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 =)

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.