Jump to content

workflow can't work when use proxy network


dorayo

Recommended Posts

Recently, I need to bring my MBP to office. But when I use Alfred2 I found the all the workflows can't work.

The office network need to set http(s) or sock proxy. I've alread set the http and https proxy. 

 

But, everything is Ok in my home network.

 

Thanks for all your help.

Link to post

Recently, I need to bring my MBP to office. But when I use Alfred2 I found the all the workflows can't work.

The office network need to set http(s) or sock proxy. I've alread set the http and https proxy. 

 

But, everything is Ok in my home network.

 

Thanks for all your help.

 

Alfred's workflows don't use the local environment, so a network based workflow needs to be aware of the proxy specifically. I had a bit of a look but can't see them at the moment, there are a few workarounds discussed on this forum though.

 

I have a ticket to investigate making this easier in workflows in the future :)

Link to post

Alfred's workflows don't use the local environment, so a network based workflow needs to be aware of the proxy specifically. I had a bit of a look but can't see them at the moment, there are a few workarounds discussed on this forum though.

 

I have a ticket to investigate making this easier in workflows in the future :)

Thanks all the same~ 

Link to post
  • 2 months later...

I also faced with same problem. For now, it gets around the problem by hardcoding the proxy url to workflow php script, but I think that there is a problem with the usability when it is a situation that has registered a large number of workflows.

 

By the way, I noticed after this, but python script that was written with urllib was not required modification of the code. Urllib  in the python script would read the environment variables for the external. you can set from the preferences if you are using OSX environment. This was a simple solution when compared to the php script.

Link to post

Yeah, it depends on the language the workflow is implemented in. Ruby and Python will use the http_proxy environmental variable (certainly if their built-in HTTP libs are used), PHP won't (AFAIK), so PHP workflow authors will have to consider proxy servers in their implementation.

 

What Andrew said isn't totally clear. Alfred doesn't use your Terminal/bash environment (set via shell dotfiles) for workflows, but it does use your OS X environment set via setenvlaunchctl setenv or /etc/launchd.conf.

 

If you set http_proxy that way, instead of in .bashrc or .profile, it should work transparently with most Python/Ruby workflows.

Link to post

If you are doing the PHP thing, then one possibility that you could do is to set the default proxy information. (This approach might not work, and the code might be a bit off, but it's the general idea).

 

So, create a php file somewhere called "filename.php" or whatever. Drop this in there:

<?php
// filename.php

if (! strpos(exec("networksetup -getautoproxyurl Wi-Fi|grep URL"), "(null)")) {
    $login = ""; // set login
    $password = ""; // set password
    $proxy = ""; // either URL or IP address
    $port = ""; // proxy port

	php $auth = base64_encode("$login:$password");

	$context = array(
		'http' => array(
			'proxy' => "tcp://$proxy:$port",
			'request_fulluri' => true,
			'header' => "Proxy-Authorization: Basic $auth",
		),
	);
	stream_context_set_default($context);
}

Next, set the blank variables above to whatever you need. Lastly, in each php workflow script/file, drop this line in there:

require_once("/my/full/path/to/filename.php");

Theoretically, it will run the code. The networksetup tool should let you know if you are behind your proxy (I'm not sure what the actual output is when you are behind one because I'm not behind any of them), and then it should set the default proxy settings for PHP to use. One nice aspect about this approach is that you just have to write the file once, and then you'll just be able to drop it into any workflow with that one line, so editing is minimal. One drawback is that the authentication information is stored in plaintext. You could get around this by creating a settings file that PHP would parse within that "if" statement and encode text password/whatever else so that it's not stored in plaintext.

 

Again, this is theoretical, and it might break. But, then again, it might work.

Link to post

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...