I have an extension that has been working for almost 2 years now with out issue. I havent made any changes in about a year, but recently i started seeing some change in behavior.
I use the Webrequest APi to intercept navigations. During the callback for some websites i need to do some security evaluations async. When this happens I redirect to a local resource (html) as an interstatial page that tells the user what I am doing. Once complete based off the evaualtion the page is redirected where it should be. This is ussually very fast and has worked great for the last 2 years. Since the latest version of chrome things dont seem to work anymore for all cases.
If i intercept an address bar navigation. everything works as expected. The interstatial pops and everythings great. However. If i click on the same website as a link on a webpage. I get the "Blocked by Extension page". (what you would get if the nav was cancelled). I also noticed that my interstatial is showing up in the web history and if i click on it from my history page everything works.
It seems as if a bug might have been introduced by google?
Just wondering if anyone has seen this.
Thanks
Related
I am scratching my head trying to figure out (and yes, I know there are multiple reasons this could be happening) why my AdSense Impressions have dropped to 0 after changing my site to Drupal 8.6.4.
I have installed the Drupal AdSense module, into which I've put my "pub-XYZ~~" account number.
I left it like that for several days thinking perhaps the crawler hadn't found it. Then I got cold feet and thought perhaps it wasn't working, especially since I didn't see any AdSense code appearing in the source of the page.
So I added the following code via Asset Injector into the head of the page:
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"> </script>
<script>
(adsbygoogle = window.adsbygoogle || []).push({
google_ad_client: "ca-pub-239656292892567776",
enable_page_level_ads: true
});
</script>
(That's not my real client ID, just random numbers.)
Now I see a line of script in the head of the page:
<script src="/sites/default/files/js/js_Gc2nyd2PQaQJQwlbfhfc8Yz8TwWRl90UGM3vTenwS8s.js"></script>
And that (if I click on it) opens up the Google AdSense code I've written above.
Yet I've waited two or three days more, still not seeing any impressions, page visits, CTR (every metric on my "Performance" report is zero), and I am concerned that maybe I've done something wrong.
So does anyone know, if I'm using the Drupal AdSense module, where do I see the code?
And two, if I'm using the module, where can I see the code appearing in the source? (The Google answer doc says "You can do this by viewing the source of your site from a browser and double-checking that the ad code looks exactly like the code we provide you in your account, and includes every line of the ad code." But in the Drupal AdSense module, the only field is one for that pub-XYZ~~~ number, and nothing else, and as I mentioned, I'm not finding the code anywhere in the site when I view the source.
Three, if I'm using the module, will it mess things up to have the code above put in via the Asset Injector?
And lastly, am I just too worried and the AdSense module is doing what it should and I should check back in 10 days or 20, rather than in 5 or 7?
Thank you for any help. I had just installed AdSense (by adding it to the head of the page, this exact code) on the old site before switching to Drupal, and it was definitely working then, so I know that the issue isn't that the site isn't approved or the account's invalid or such. It WAS working fine. But after this move to Drupal 8, it's completely failed and I just don't know which link of the chain is the one I should fix. I have been scouring both Drupal docs and AdSense docs for this issue/answers and haven't found anything that seems to be the issue...and I really am hoping to know if the code side of it is correct.
Again, thank you in advance!
Okay, so for anyone else who needs this info, I'm answering my own question: I never did get the Google AdSense "auto ads" to work on my site, and am pretty sure the reason they didn't is that I was trying the "auto ads" code rather than the on-the-page, placed ads type code. I still don't know if it was simply a matter of time and the crawler hadn't found my site again, or if I had incorrect code, or what.
But I am now seeing an ad on my site, and what worked for me was:
Turn off any AdSense code in the head of the page. (I had injected the script via Asset Injector, and I disabled that.)
Make sure Drupal's AdSense module is running. DEselect the option that asks people if they wish to turn off their adblocker. The only thing I added in AdSense's main config window was my "pub-XYZ~" number.
Ditch the Google "auto ad" option and do the "Ad Units" option, creating an ad in AdSense. (AdSense > Ads > Ad Units). Do everything there and get your ad ID#.
Back to Drupal: Either create a new custom block or use one of the Drupal AdSense options to create a block on your site. If you use an Drupal AdSense option, it prompts you for the info needed to display the right ad. You'll need that ad ID# info at the very least.
Make sure that block is placed on your page. I chose "Responsive" but presumably this works for all the options. Fixed size, etc. I believe you could also (if you wanted) simply place the Google code directly into a custom block and use that. It seems people do.
If you've done it right, logged into your Drupal site, with the block placed, it will show placeholder text with your pub-# and ad ID#, in a little box. You won't see an actual ad (this is in the "Help and Information" option at the top of the AdSense module config). If you're seeing the placeholder box, it's a good sign that everything's going well with the Drupal AdSense module side of it.
Then wait, and wait, and eventually, logged out, on a private browser window, you should see the ad when the crawler finds it and other magic happens. I waited about 24 hours after setting this whole thing up before seeing an ad appear.
(Please note that this all was with a site that had a working AdSense account and had previously been getting lots of impressions for the ads. So if you don't have those aspects set up initially, none of the above will work either.)
Today I was starting a web app I am developing that embeds a Spotify widget player in an iframe. Strangely it doesn't load the widget and instead reports this message
"open.spotify.com redirected you too many times"
I went to Spotify Widget examples page and it shows the same behaviour (here's a ).
I cleaned the the cache, cookies, but it doesn't seem to sort this. Should I assume there is an API request threshold that I've just hit?
Has anyone have had the same problem and has solution?
Thanks
That was a temporary issue in our service. It's resolved now.
This has been driving me nuts all day:
I have an iOS app with a custom URL scheme defined, and am trying to share a link on FB which points to a page that has this scheme in its applink meta tags, so that tapping it should fire up my app.
Every little piece of it is working just fine. I can enter my URL scheme in safari on the phone and the browser launches my app. I have tested my webpage with the FB debug tool and there are no errors or warnings - it correctly identifies all the meta tags.
If I share the link using FB on the phone or on my laptop, all works fine.
HOWEVER, if I share the exact same link using FBSDKShareDialog, it does not work. It just opens the web page with the meta tags as if it was any regular web page.
Anyone has any idea why these two ways of sharing would be different? They look exactly the same otherwise.
If anyone else runs into this problem, here's the reply from FB:
When you share with mode automatic, the app does a fast app switch over to the FB app to show the native share dialog
The post is cached locally on the device, and it does not know about app links (since only Facebook server side knows about it)
When the user opens the FB, the user sees their cached story (with no app links behavior),
This doesn't manifest with the Web mode since the Facebook app needs
to pull from the server to get the post, in which case it has all the
app links info.
This is unlikely something that we'll fix. However, after a while, the
cache will expire, and Facebook app will re-pull the posts from the
servers, in which case the app link data will be available.
In order to test this, you can share the post on one device, and then
try clicking on the post from another device. The app links should
work at that point.
Which is kind of a lame response IMO - they parse the target page to build the preview, how hard would it be to remember the applink and use it?
There could be two possible issues:
Either the one told by #NJ, i.e. you are just trying to open the link in Facebook app, using the same device from which you posted the link.'
Solution - either open link in other device or cose and re-open your facebook app and do multiple refresh
Or You have some error in your meta tags. There is one important thing though, that Facebook never mentions, i.e. they cache the URL you provide.
So any one used the web link with meta tags the first time in Facebook, Whole meta tags will be cached, and you updated meta tags won't be parsed by facebook.
Solution
To get over with the issue, use below link
Facebook debug tool
Input your meta data included web page URL and
-click on show existing scrape information to find any error
Click on Fetch new scrape information for refreshing your URL on facebook. it will clear the cache for that URL in facebook server.
I really hope someone can tell me more about what's going on, because I spent days searching the net and for the life of me can't say what is going on.
Here's what happened. I have a website 4nieuws.nl . On every article's page I put a like button using the Javascript SDK. All worked well. On facebook I created a fanpage for the website, facebook.com/4nieuws and every now and again I would copy an interesting article there. The like button and Javascript SDK on 4nieuws.nl uses the APP Id from an app I created specifically for that purpose.
Then I thought I might automate to publish the most popular articles on the fanpage using the PHP api. I set about getting the proper authorization key using the sequence explained on this page: http://www.typeoneerror.com/articles/post/permanent-facebook-sessions-and-posting-as-a-page
For this to work I authorized the previously mentioned app to publish on the facebook fanpages that I am admin of. And this works.
Now for the strange part. Ever since I authorized the app, if I go to 4nieuws.nl and like a page, or even 'post to facebook', the button shows 1 more like. But the like message never shows up on my personal wall. My wife, logged in to her own facebook account, gets a notification that I liked a page, but when she clicks the notification she is sent to a Facebook 404 page. When I subsequently reload the article, my 'like' is not there anymore.
Has anyone ever come across something like this ? I'm a bit anxious because I am not sure if other peoples likes on 4nieuws.nl are working as it should. I do see likes on pages but have no idea if those likes are actually registering on peoples walls.
Any help greatly appreciated.
I got a solution for Firefox and IE but I didn't find any solution for Google Chrome.
Is there a way to do it in Google Chrome?
I know it's a really old post... I mean like friggin 5 years now, but I just found a somewhat good solution.
Inside your protected folder, create another folder, let's call it "logout". Place the same .htaccess file in here as you have in your protected folder, except with a small modification.
instead of:
Require valid-user
now write:
Require user EXIT
And make sure, you don't have a user named exit! :D
In your protected area, your logout link or button or whatever, should redirect the user to this address: example.com/protectedFolder/logout
The browsers usually are able to keep only one user logged in from one site name or realm name... the sign in attempt for the user Exit will overwrite everything, thus the originally logged in user, would have to log in again to the protected area.
But as always, I might be wrong, and you should still close all your browser window, and restart the computer if you want to be sure! :)
Also, it wouldn't hurt, if you would tell your users what is going to happen, when they hit logout!
I have tested this in chrome and in internet explorer 11.(will not work in edge, and maybe others neither)
The solution was found here:
https://www.mavensecurity.com/media/BasicAuthLogOut.pdf
You can't logout a HTTP authenticated session other then closing the browser window. Also see the accepted answer on this question for an extensive explanation.
try redirect to:
wrong_user:wrong_password#yourdomain.com
I have put together the following article which explains how I have managed to achieve this in Chrome. I hope this helps. https://www.hattonwebsolutions.co.uk/articles/how_to_logout_of_http_sessions
In short - you create a sub folder (as per Gyula's answer) but then send an ajax request to the page (which fails) and then trigger a timeout redirect to the logged out page. This avoids having a secondary popup in the logout folder requesting another username (which would confuse users). My article uses Jquery but it should be possible to avoid this.