Privoxy whitelist faulty on redirect - raspberry-pi

My problem, in a nutshell, is the following:
I use Privoxy to set up a whitelist of sites in Raspbian Jessie on Chromium. I have Chromium start on boot with the following snippet in lxsession/LXDE-pi/autostart:
#privoxy
#chromium --incognito --kiosk --proxy-server=127.0.0.1:8118
This does work as intended, with every site except the ones I specify blacklisted.
Now I edited /privoxy/templates/blocked so that instead of the usual site it will give me a redirect to a certain site should a link be opened that is not on the whitelist:
<!DOCTYPE html>
(Stuff happens)
Please go back to this site.
example.com being one of the sites I whitelisted. The problem is, it simply redirects me to the "blocked" page again, making me stuck in a loop. Does anyone have a clue why this would be and how I could work around it? I tried using
window.history.back()
however it doesn't seem to work either.
I use Kiosk mode because I want to use this in a context where entereing URL-adresses is not desired, just to clarify my Chromium-call.

Well, I solved it, at least partially. Turns out that I need to add http:// in front of the URL, since it gets added to the already existing URL otherwise. Which is fair, but a bit awkward for me to admit. HTML isn't exactly my forté. Marking it as solved and keeping it, just in case somebody stumbles upon a similar problem.

Related

ModalPopupExtender doesn't show on some computers

I maintain a vb.net website. A button on a page shows an AjaxControlToolkit.dll ModalPopupExtender. When I click the button, the page reloads, but no popup appears.
My tests below cover the scenarios I can think of. Please help me diagnose and fix.
This ModalPopupExtender succeeded in the past. The error might have started when we moved to a new server, or when we implemented https, or a browser update, or at some other time since then.
Tried Chrome (latest) and Firefox.
I RDPed into the server and opened the page in Chrome there. ModalPopupExtender succeeded. Same Chrome version as my PC. So, unlikely to be a code issue.
A different page on the same site uses ModalPopupExtender successfully. So, unlikely to be local PC settings.
I put lines of test code immediately before and after ModalPopupExtender.Show(). Both succeed.
Aha - found it!
Solution
The ASPX/HTML referred to http://ajax.googleapis.com. Changing the references to https made ModalPopupExtender.Show() work correctly for me.
Explanation/Diagnosis (if you can clarify further, please comment)
When I checked the html served to my browser, I noticed it defined a javascript function called fn(). The definition for fn() didn't appear in the html served to the server's browser. After the https change, fn() no longer appears in the html I receive. The other page, where ModalPopupExtender worked, didn't have any reference to googleapis.com.
I assume that using http instead of https caused ajax.googleapis.com to provide fn() and that fn() in some way interfered with the normal operation of my ModalPopupExtender.
Here's the fn() definition: (function {var fn = function() {Sys.Extended.UI.ModalPopupBehavior.invokeViaServer('ctl00_cphContent_ModalPopupExtenderConfirm', true); Sys.Application.remove_load(fn);};Sys.Application.add_load(fn);})();
Note: the http also included another javascript function related to the ModalPopupExtender. But there was a similar one on the working page, and in the working version served to the server's browser, and in my fixed version. So, I assume that function is correct.

How do relative URLs work in Sinatra?

I am hosting my Sinatra application using Apache with Passenger. It's hosted within a subfolder -- meaning, my main site is example.com, my application is at example.com/popcorn.
So I have a get '/' route, and that works fine. The problem is that my view includes a HTML form that makes a post request to upload, and the post '/upload' route isn't handling it. Instead of example.com/popcorn/upload, it's trying to get example.com/upload.
So I figure okay, not the ideal solution, but for now I'll hardcode the form action URL. But that doesn't work either -- making the action popcorn/upload fails too. This is where I get a little baffled, and my Google-fu was weak, I couldn't find help there.
Maybe I could have some kind of Apache rewrite rule, but is that the correct solution? Am I missing something? I would really appreciate a tip here because it feels like I've messed up something very simple and it's really bugging me.
You probably want the url helper method. That takes into account where the app is mounted on the server:
url('/upload')
The above code will evaluate to something like this:
http://example.com/popcord/upload
Inside your app you shouldn’t need to change anything, this will be routed to the existing post '/upload' handler.

Drupal site redirects to installation page

I was working on my branch this morning tweaking some CSS when all of a sudden my Drupal site went into a dead mode. I am running multi site mode and the local.settings.php in the individual sites is being ignored on load.
The parent settings.php file is also being ignored on load.
The site redirects to the installation url: http://site.local/install.php
What could have possibly went wrong and how do I go about resolving that?
I finally figured it out. For some reason it had everything to do with the settings in the sites.php The mapping was not 100% correct even though it initially worked. I had to re-map my multi-sites domains in the sites.php and it worked. So if that happens, double check your multi-sites settings. Make sure domain names match and that your database credentials are correct.. [see above]

Pow works locally, but serves other site on xip.io

I'm using Pow.cx for local development servers - Rails, PHP and static. It's working fine locally, but when I try to use the new xip.io functionality to browse from another device I'm getting a different localhost site every time.
This particular incorrectly-served site is not set up in Pow, but I have an older virtual host set up for it.
Put another way:
stm.dev serves the correct site on my desktop.
stm.192.168.1.XXX.xip.io on my iPhone serves up a different site that is not configured in Pow.
I haven't been able to find any mention of a similar problem online, has anyone else come across this? This particular site is static html, if it matters.
So far I have been unable to get Pow to automatically pick up the xip.io addresses. However I did finally get it working to the point that I can continue building the site.
I followed the instructions from this link http://blogs.adobe.com/shadow/2012/06/19/shadow-xip-io-virtual-hosts-workflow-simplified/ in setting up a vhost alias for the site. I believe that cuts Pow out of the loop, but at least it's working now for testing on the other devices I need.
I would love to have Pow working as described, so if there are any suggestions on that end I'd love to hear it.

window.CavalryLogger error in Facebook App running in Facebook Page Tab

I have applications which are displayed as tabs in Facebook pages which have been working fine. They suddenly started displaying this output in the tab:
/1336720089,176820405/
if (window.CavalryLogger) { CavalryLogger.start_js(["EgxV3"]); }
__d("UFIUpdate",
Any ideas what is going on???
Here is a link to one of them: http://www.facebook.com/TweakShoes/app_132692060112327
A temporary solution is to add https:// to facebook itself. This doesn't solve the problem, but it'll allow you to see your page on a per client basis.
The best fix in the longer term until facebook fixes this issue is to go to your account settings > Security > Enable secure browsing. This will enforce HTTPS wherever it can and should resolve the issue for a lot of pages you're trying to access.
Good Luck!
After encountering this issue yesterday, I tracked it down to an apparent conflict with the JS log wrapper included as part of HTML5 Boilerplate's script.js file. In particular, the "make it safe to use console.log always" snippet. After commenting it out, the FB lib error went away and my app displayed properly.
I didn't dig into what the conflict was, but here is the snippet. If you use something similar on your page, then it may be worth investigating.
/* make it safe to use console.log always */
(function(b){function c(){}for(var d="assert,count,debug,dir,dirxml,error,exception,group,groupCollapsed,groupEnd,info,log,timeStamp,profile,profileEnd,time,timeEnd,trace,warn".split(","),a;a=d.pop();){b[a]=b[a]||c}})((function(){try
{console.log();return window.console;}catch(err){return window.console={};}})());
It's probably not a coincidence that FB's own logger bugs out with this.
Facebook has opened a bug for this issue and recently triaged it to medium priority - no word on when it will be addressed.