I created a new website using a newly registered domain.
When trying to share it as a link in Facebook, it is classed as "spammy" and I'm unable to share it.
After a few weeks of research and reporting to FB I copied the site entirely and placed on a new TLD.
This has instantly become blocked on facebook which made me think there's something within the structure of the site which is causing it to be marked as spam.
Using object debugger on the original URL has given a number of various responses such as:
"Error parsing input URL, no data was scraped"
Response code 206
Response code 203
I read that using chrome can bug it out so I used firefox and safari to check.
Does anyone have any idea why the response codes vary for a static site?
Are there any specific site setups which are currently causing FB to block?
I have read that certain .htaccess configs, such as www>non-www can upset FB, is this true?
The sites in question are:
Link 1 (this was intended to be the only domain)
Link 2 (this was setup only when original domain was blocked)
These domain are new, never been used for spamming or mail.
I have checked all the blacklists I could possibly search and have not found anything that indicates problems.
It really does seem that there is something in the configuration of the site that is causing it to be blocked. Does anyone have any idea or experience in this??
I was able to scrape the page correctly using the Debug Lint tool:
http://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.sophie-mcelligott.com%2F
Maybe facebook block newly registered domains for a fixed time before letting you share it on Facebook, presumably to stop spammers. Are you able to scrape both sites correctly?
Related
Apologies if this is a roundabout way of asking this question, but I am a little confused about how the web and javascript work.
What I want to do: execute javascript on all pages of a list of urls I have found. (Specifically use jquery to pull info from them)
Problem I can't execute Javascript on these pages because they aren't mine and don't have the Access-Control-Allow-Origin header. So I can't load them (with AJAX) in order to use JQuery on them.
BUT Google Chrome can both load pages and execute javascript on them (with their developer's console). So if I wanted too, I could go to each page, open the developers console, and pull the information from there. If there's nothing stopping Chrome from accessing these, then why am I stopped? And, is there a way around this?
Thank you, and I hope my description makes sense. I've been researching this for a while but have found nothing that explains how seemingly inconsistent CORS is.
I could go to each page, open the developers console, and pull the information from there. If there's nothing stopping Chrome from accessing these, then why am I stopped?
You're not stopped. You, the human at the keyboard, can do exactly as you say, by visiting each page as a top-level page.
What is stopped -- happily -- is any and all scripts on the Web you happen to run having the same level of visibility that you do. Based on your cookies and your network topology, you have a unique view into the Web. You can see your home router's control interface (on 192.168.1.1 or similar). You can see any local web server you're running on 127.0.0.1. No one else can see these. If the same-origin policy were not in place, then any script that you loaded on the Web could inspect these.
And, is there a way around this?
If you have some scripts that you trust absolutely (hopefully a significant subset of "all scripts that exist on the Web") that you want to be able to bypass the same-origin policy and see your full, cross-domain view of the Web, you could load them as an extension, which can act with elevated permissions beyond the abilities of normal web pages. (See How does Same Origin Policy apply to browser extensions?)
I'm going to assume that you are looking to grab data from these pages that aren't yours and store it somewhere. I have done this before with curl using php. If you are looking to display these sites for users to interact in a different way, but starting from a page that is yours, you may be able to render these pages by grabbing the source html using curl and rendering it as a sort of proxy.
I've used this tutorial for something similar https://www.youtube.com/watch?v=_kQN-3aNCeI . Hopefully this gives you a start. I think you should be a little more detailed in your question though to get more help.
Trying to use the StockTwits Widget in a web page that is (and must remain) served over SSL.
Since the widget-loader.min.js script link was being called via http, I copied the code to our domain so it would be served over our SSL. Problem still not solved. Chrome 25 says my page "ran insecure content" and completely refused to run or even display the widget.
So I dug into the .js file and found this little bit:
m=b.ssl?"https://":"http://"
Figuring the warning was coming from the widgets CALL to the service, I hacked this line as follows:
// add one character ↓
m=b.ssl?"https://":"https://"
Initially I thought I had success, because Chrome 25 loaded the widget! But my glee was short lived once I saw that the nice GREEN https:// in the address bar had changed to a yellow warning sign. Clicking it for info revealed a warning: "...displayed insecure content from http://assets1.stocktwits.net....". {darn}
Since the .js is secure, and the CALL to stocktwits is made with https thanks to the hack, I have to conclude that stocktwits either isn't able or configured to reply over HTTPS.
Do you have any experience with this widget, or see something I am not doing correctly? TIA.
We've fixed the widget to use protocol-less URLs now. Let us know if that fixes this issue for you.
Currently the widget is not fully SSL compatible.
We will look into seeing what would be involved to have an SSL option with the widget. Seems like it could be done with minimal impact.
The Context:
You have a web server which has to provide an exclusive content only if your client has your specific Chrome extension installed.
You have two possibilities to provide the Chrome extension package:
From the Chrome Web Store
From your own server
The problem:
There is a plethora of solutions allowing to know that a Chrome extension is installed:
Inserting an element when a web page is loaded by using Content Scripts.
Sending specific headers to the server by using Web Requests.
Etc.
But there seems to be no solution to check if the Chrome extension which is interacting with your web page is genuine.
Indeed, as the source code of the Chrome extension can be viewed and copied by anyone who want to, there seems to be no way to know if the current Chrome extension interacting with your web page is the one you have published or a cloned version (and maybe somewhat altered) by another person.
It seems that you are only able to know that some Chrome extension is interacting with your web page in an "expected way" but you cannot verify its authenticity.
The solution?
One solution may consist in using information contained in the Chrome extension package and which cannot be altered or copied by anyone else:
Sending the Chrome extension's ID to the server? But how?
The ID has to be sent by you and your JavaScript code and there seems to be no way to do it with an "internal" Chrome function.
So if someone else just send the same ID to your server (some kind of Chrome extension's ID spoofing) then your server will consider his Chrome extension as a genuine one!
Using the private key which served when you packaged the application? But how?
There seems to be no way to access or use in any way this key programmatically!
One other solution my consist in using NPAPI Plugins and embed authentication methods like GPG, etc. But this solution is not desirable mostly because of the big "Warning" section of its API's doc.
Is there any other solution?
Notes
This question attempts to raise a real security problem in the Chrome extension's API: How to check the authenticity of your Chrome extension when it comes to interact with your services.
If there are any missing possibilities, or any misunderstandings please feel free to ask me in comments.
I'm sorry to say but this problem as posed by you is in essence unsolvable because of one simple problem: You can't trust the client. And since the client can see the code then you can't solve the problem.
Any information coming from the client side can be replicated by other means. It is essentially the same problem as trying to prove that when a user logs into their account it is actually the user not somebody else who found out or was given their username and password.
The internet security models are built around 2 parties trying to communicate without a third party being able to imitate one, modify or listen the conversation. Without hiding the source code of the extension the client becomes indistinguishable from the third party (A file among copies - no way to determine which is which).
If the source code is hidden it becomes a whole other story. Now the user or malicious party doesn't have access to the secrets the real client knows and all the regular security models apply. However it is doubtful that Chrome will allow hidden source code in extensions, because it would produce other security issues.
Some source code can be hidden using NPAPI Plugins as you stated, but it comes with a price as you already know.
Coming back to the current state of things:
Now it becomes a question of what is meant by interaction.
If interaction means that while the user is on the page you want to know if it is your extension or some other then the closest you can get is to list your page in the extensions manifest under app section as documented here
This will allow you to ask on the page if the app is installed by using
chrome.app.isInstalled
This will return boolean showing wether your app is installed or not. The command is documented here
However this does not really solve the problem, since the extension may be installed, but not enabled and there is another extension mocking the communication with your site.
Furthermore the validation is on the client side so any function that uses that validation can be overwritten to ignore the result of this variable.
If however the interaction means making XMLHttpRequests then you are out of luck. Can't be done using current methods because of the visibility of source code as discussed above.
However if it is limiting your sites usability to authorized entities I suggest using regular means of authentication: having the user log in will allow you to create a session. This session will be propagated to all requests made by the extension so you are down to regular client log in trust issues like account sharing etc. These can of course be managed by making the user log in say via their Google account, which most are reluctant to share and further mitigated by blocking accounts that seem to be misused.
I would suggest to do something similar to what Git utilises(have a look at http://git-scm.com/book/en/Git-Internals-Git-Objects to understand how git implements it), i.e.
Creating SHA1 values of the content of every file in your
chrome-extension and then re-create another SHA1 value of the
concatenated SHA1 values obtained earlier.
In this way, you can share the SHA1 value with your server and authenticate your extension, as the SHA1 value will change just in case any person, changes any of your file.
Explaining it in more detail with some pseudo code:
function get_authentication_key(){
var files = get_all_files_in_extension,
concatenated_sha_values = '',
authentication_key;
for(file in files){
concatenated_sha_values += Digest::SHA1.hexdigest(get_file_content(file));
}
$.ajax({
url: 'http://example.com/getauthkey',
type: 'post'
async: false,
success:function(data){
authentication_key = data;
}
})
//You may return either SHA value of concatenated values or return the concatenated SHA values
return authentication_key;
}
// Server side code
get('/getauthkey') do
// One can apply several type of encryption algos on the string passed, to make it unbreakable
authentication_key = Digest::<encryption>.hexdigest($_GET['string']);
return authentication_key;
end
This method allows you to check if any kind of file has been changed maybe an image file or a video file or any other file. Would be glad to know if this thing can be broken as well.
We've got a number of content managed sites that use the same functionality. We added a site recently, and the Facebook like button is failing with an error on-click (following Facebook login):
This page is either disabled or not visible to the current user.
This only happens when the Facebook user isn't an administrator of the page, or of an application we've created for the page.
The site where this is failing is here: http://beachhousemilfordonsea.co.uk/
An example of a site that works (same code): http://monmouthash.co.uk/
The Facebook like code:
<fb:like href="http://beachhousemilfordonsea.co.uk/" width="380"></fb:like>
Actions already taken
I've checked with the FB Linter and there are a couple of Opengraph warnings that do need to be fixed (add a description, increase the image size) - but these are the same for all sites so should be affecting this (it's on the dev plan to get these rectified in the next release).
I've taken a look at the Facebook App we've got running on the problem page, and checked it against other working applications and the settings are the same as far as I can see, except there are missing options with this new application:
Encrypted access token (assume this is default, not changeable now)
Include recent activity stories
It doesn't feel like the application should have much of an impact on this though, as we use the application for the other functionality within the page (which is all working fine!).
I've searched for possible issues, and checked the more common ones:
There are no age/geographic restrictions
I've submitted 2 requests to Facebook in case the content is blocked, but no response or change
Any recommendations as to what else to try?
Thanks in advance,
Kev
P.S. I asked this question a week ago but it wasn't well formed - hopefully this is a better attempt, but if you need anything else please do let me know.
I've been working on this particular error for a week now, debugging different social buttons and narrowing it down to Facebook in general: every "Like" button I've implemented (HTML5, xfbml, etc.) triggers the same cross-domain scripting error. Basically, Facebook is triggering this error with every iFrame (like below) upon clicking "like":
Unsafe JavaScript attempt to access frame with URL http://mediacdn.disqus.com/1326940420/build/system/def.html#xdm_e=http%3A%2F%2Fwww.vancitybuzz.com&xdm_c=default4311&xdm_p=1& from frame with URL http://www.facebook.com/plugins/like.php?channel_url=https%3A%2F%2Fs-static.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%3Fversion%3D3%23cb%3Df31a0247d%26origin%3Dhttp%253A%252F%252Fwww.vancitybuzz.com%252Ff3c0eb7e0c%26relation%3Dparent.parent%26transport%3Dpostmessage&extended_social_context=false&href=http%3A%2F%2Fwww.vancitybuzz.com%2F2012%2F01%2Fchinese-new-year-events-2012-vancouver-richmond-burnaby%2F&layout=box_count&locale=en_US&node_type=link&sdk=joey&send=false&show_faces=false&width=90. Domains, protocols and ports must match.
Why this isn't a duplicate: the issue occurs even in the absence of the twitter button and google+ button. it also occurs in every implementation of the "like" button. the symptoms point to a new issue.
Methods attempted: I've tried multiple "versions" of the Like button all with the same issue. It's even conflicting with DISQUS.
Suspects: Pages that do not have any DISQUS code are functioning normally. This variable (output by DISQUS wordpress plugin) is suspect:
var facebookXdReceiverPath = 'http://www.vancitybuzz.com/wp-content/plugins/disqus-comment-system/xd_receiver.htm';
In addition, javascript output by Facebook is also suspect.
See it yourself: Go to http://www.vancitybuzz.com/2012/01/research-in-motion-ceos-resign/ it's likely to change, though.
The Question
Given the information here, does anyone know of a workaround to force out the cross-domain error? Many thanks.
After multiple people have looked into this, including myself, currently there is no workaround for cross-domain errors because Facebook uses iFrames for communication.
This would also apply to the Google Plus button as it stands today.
However, the future looks bright. Google devs (and likely Facebook, too) have confirmed they are working on a new solution.
In the meantime, some people have reported that using Facebook and other widget plugins seem to alleviate the problem in Wordpress-structured sites. No guarantees.
http://mashable.com/2010/05/07/wordpress-facebook-like-buttons/
The Future: I wouldn't be surprised if websockets (and flash ws fallbacks) are used, but I'll leave that to the platform devs