Cookie Support

[joshdick]

Very quick and dirty cookie support. NOT production ready (yet).

Use this cookie support code at your own (security/disk space/etc) risk.

Missing:

• Error checking
• Cleanup of cookiefiles
• Session expiry
• Ability to toggle cookie support (should disable by default)

[BelleNottelling]

So this bit of code tells curl to use the $cookieFile to store cookies?

$cookieFile = sys_get_temp_dir() . "cookiefile_" . session_id() . "_" . $host;

	curl_setopt($ch, CURLOPT_COOKIEJAR, $cookieFile);
	curl_setopt($ch, CURLOPT_COOKIEFILE, $cookieFile);

[joshdick]

Yup!

[BelleNottelling]

@joshdick I just put this togeather really quickly, is this code correct to toggle cookies? (the variable would be in the config at the top)

if(!enablecookies){
	//If we don't need cookies delete old ones 
	$mask = 'cookiefile_*.*';
	array_map('unlink', glob($mask));
  }else{
	$cookieFile = sys_get_temp_dir() . "cookiefile_" . session_id() . "_" . $host;

	curl_setopt($ch, CURLOPT_COOKIEJAR, $cookieFile);
	curl_setopt($ch, CURLOPT_COOKIEFILE, $cookieFile);
  }

[joshdick]

That could would make sense in the case where cookies were switched from enabled to disabled, but if cookies were never enabled, there'd be no reason to glob for cookiefiles that wouldn't exist on every invocation of the proxy. Also, the else logic would need to include all added lines that appear in 86aaf53.

[BelleNottelling]

@joshdick
Okay, so I think this might be a decent solution for now. Basically, to clean the cookies you just have to enter the URL as "cleancookie". After that, I added the necessary code to the else statement and it will no longer try to delete the cookies if they are disabled.

if(url == "cleancookie"){
	$mask = 'cookiefile_*.*';
	array_map('unlink', glob($mask));
  }
  
  if(!enablecookies){
	//No use for this right now.. 
  }else{
	session_start();
	
	$parseUrl = parse_url(trim($url));
	$host = trim($parseUrl['host'] ? $parseUrl['host'] : array_shift(explode('/', $parseUrl['path'], 2))); // http://stackoverflow.com/a/1974047/278810
	$cookieFile = sys_get_temp_dir() . "cookiefile_" . session_id() . "_" . $host;

	curl_setopt($ch, CURLOPT_COOKIEJAR, $cookieFile);
	curl_setopt($ch, CURLOPT_COOKIEFILE, $cookieFile);
  }

[joshdick]

That could work. When I had opened this PR I had thought of a few ways to clean up cookies automatically:

• Having some new "cookie cleanup" part of miniProxy automatically triggered as a server-side script periodically by something like cron or systemd
• Having miniProxy check for cookie files that are older than some certain age and clean up those files, triggered on every incoming request, similar to your first idea above, but I fear that would slow down miniProxy requests too much.

I hadn't considered having an explicit URL to do the cleanup, but it's certainly the simplest!

[BelleNottelling]

@joshdick It is deffinilty easier, I looked back at it and realized that I broke it by putting url instead of $url, so that is fixed now. Here is the corrected script.. Problem is that I don't know where the cookies are stored or how to make them be cleaned, I have the base code, but it needs to be updated so it will look in the correct path.

if($url == "cleancookie"){
	$mask = 'cookiefile_*.*';
	die('Detected Cookies: "' . glob($mask) . '" Have been deleted');
	array_map('unlink', glob($mask));
  }

Also as to cleaning the cookies with cron this may be of interest:
http://stackoverflow.com/questions/11297945/passing-get-parameters-to-cron-job

[Timsonrobl]

My first idea was just to add prefixes to all cookies names when setting them in users browser and stripping them when sending back to remote server. This requires using "path" attributes to control which cookies are sent to the server and thus setting up ModRewrite or whatever to have a clean construction like: webproxydomain.com/arbitrary_path/somesite.com so you can identify remote domain by path.
The only problem is - you would get defferent cookies for webproxydomain.com/arbitrary_path/somesite.com, webproxydomain.com/arbitrary_path/http://somesite.com and webproxydomain.com/arbitrary_path/https://somesite.com
The secure solution is to form URL so that protocol goes after domain like webproxydomain.com/arbitrary_path/somesite.com/https/internal_path/ It doesn't look that clean but allows you to preserve original cookie path control in case the remote site actually uses path attribute for some security reasons.