According to this post
a typical firefox user has 2-3 tabs open.
How can they say that ?
Does Mozilla receive user statistics from firefox?
Can you get this information using javascript ?
Can you get this information with other browsers ?
Yes, they do get certain user statistics, and I assume this is one of them. You can't access this in regular content (web page) JavaScript, in any browser, as far as I know.
Related
I am working on ponds site and want to open the below mentioned url: www.ponds.co.id/Products/Category/Whitening-2.aspx
But this page is always redirected to default page : www.ponds.co.id.
How can i stop this redirection in dnn?
Thanks,
#John - Without some more info this is a bit hard to diagnose. Things I would check:
That the page settings does not have a redirect to the home
That the page allows visitors (i.e. security is not restricting them)
That you are not getting some errors in the event viewer that would explain it.
I will try to explain a bit the context for my problem.
Context:
A while ago I started working on Facebook application. One of the requirements is to be included in a Facebook page as a tab. This application will contain on a page a send button in order to be able to make it more engaging with specific people, users of the application would choose on their own. The reason behind this is because the Facebook page containing the application is related to alcohol, and "liking" the application will get more audition and potential children. Another reason for using send button rather then other similar options from Facebook (like send dialog etc.) is because in Facebook documentation was stated that send button works on mobile devices and other options don't.
Problem:
My problem is related to the send button. What I need is to be able to completely configure the send button: url, image, title, description. I have research the open graph tags in order to be able to do this. Everything works fine if the page I want to be sent with the message is a website OUTSIDE Facebook. Once I started to use the url of a Facebook page (let's call it www.facebook.com/mycustompage), then the crawler takes the images, title, description from facebook.com ignoring the actual page and the produced message is not what I want.
I have searched a lot to better understand this limitation and could not find anything relevant.
The only article I could find as a potential solution was (and even this I had trouble finding):
Send button returning error codes, like button works fine
The above discussion is a workaround which I have already put in place but is not 100% what I want. The described workaround is about putting in the send button:
<div class="fb-send" data-href="http://www.mycustomdomain.com/og"></div>
a page that sniffs the user agent. In case the user agent is Facebook crawler to serve an html empty page just with the open graph tags, otherwise redirect to the desired URL - which in our case is the facebook page www.facebook.com/mycustompage.
The message produced contains:
the title which is a link to www.mycustomdomain.com/og which when
clicked opens a page in a new tab with the address
www.facebook.com/mycustompage - this is relatively ok
under the title I have a "sub-title" readonly text containing the domain of the link: www.mycustomdomain.com - THIS IS NOT OK since I don't want to share where I have hosted the application.
the image and the desired description - this is ok.
Conclusion:
What I want to know if there is a better way to do this rather than this workaround.
If not I would like to know how I can hide for the produced message the "sub-title" so that the hosted domain is not visible.
We are developing an app that makes posts on behalf of our users to Facebook. Within those posts, we want to put links to external (non-Facebook) websites.
Looking at the links in the status bar of the browser (usually Chrome), the correct URL is displayed. However, Facebook seems to wrap the actually-clicked link into some extra bells-and-whistles. Usually, this works correctly.
Sometimes, however, this URL wrapping ends up sending the click to a URL like:
http: //spywaresite.info/0/go.php?sid=2
(added space to make it non-browsable!) which generates Chromes severe warning message:
This happens very occasionally on Chrome, but very much more often in the iOS browser on the iPhone.
Does anyone have any pointers as to how to deal with this?
EDIT
For example, the URLs we put in the link is
http://www.example.com/some/full/path/somewhere
but the URL that actually gets clicked is:
http://platform.ak.fbcdn.net/www/app_full_proxy.php?app=374274329267054&v=1&size=z&cksum=fc1c17ed464a92bc53caae79e5413481&src=http%3A%2F%2Fwww.example.com%2Fsome%2Ffull%2Fpath%2Fsomewhere
There seems to be some JavaScript goodness in the page that unscrambles that and usually redirects correctly.
EDIT2
The links above are put on the image and the blue text to the right of the image in the screenshot below.
Mousing over the links (or the image) in the browser shows the correct link. Right-clicking on the link and selecting "Copy Link Address" gets the fbcdn.net link above (or one like it). Actually clicking on the link seems to set off some JavaScript processing of the fbcdn.net link into the right one... but sometimes that processing fails.
I'm not 100% sure what you're asking here, but i'll tell you what I know:- are you referring to this screen on Facebook?
(or rather, the variation of that screen which doesn't allow clickthrough?)
If you manually send a user to facebook.com/l.php?u=something they'll always see that message - it's a measure to prevent an open redirector
if your users are submitting such links, including the l.php link, you'll need to extract the destination URL (in the 'u' parameter)
If you're seeing the l.php URLs come back from the API this is probably a bug.
If links clicked on facebook.com end up on the screen it's because facebook have detected the link as suspicious (e.g. for URL redirector sites - the screen will allow clickthrough but warn the user first) or malicious/spammy (will not allow clickthrough)
In your app you won't be able to post links to the latter (an error will come back saying the URL is blocked), and the former may throw a captcha sometimes (if you're using the Feed dialog, this should be transparent to the app code, the user will enter the captcha and the dialog will return as normal)
If this isn't exactly what you were asking about please clarify and i'll update my answer
Rather than add to the question, I thought I'd put more details here.
It looks like the Facebook mention in the original title was mis-directed, so I've removed it.
We still haven't got to the bottom of the issue.
However, we used both Wireshark and Fiddler to look at the HTTP traffic between the Chrome browser (on the PC) and Facebook. Both showed that Facebook was returning the correct URL refresh.
Here's what Wireshark showed:
What we saw on Fiddler was that our server is issuing a redirect to the spywaresite.info site:
We are working with our ISP to figure out what is happening here.
I use this
\ a class="fb-button" href="https://www.facebook.com/dialog/oauth?client_id=184082381694xx8&redirect_uri=https://xxxxxxx.com&display=popup" \
although it seems to changing the way the oauth displayed it doesn't open as a pop up but
as a new tab.
How can I do a popup facebook login like this one https://www.airbnb.com/login ?
You need to include the Facebook JS SDK for those popups to work correctly. Instructions on how to include the SDK are available in the developer documentation.
I had the same problem and I did including the javascript SDK as avist suggested. Here are the conclusions of my experience/research:
I couldn't get display=popup to work, this is not surprising as many things in the facebook doc don't really seem to work.
Airbnb (in the example Sergi linked to) implements their own popup. There is a pretty good example of how to do it here http://thinkdiff.net/facebook/create-facebook-popup-authentication-window-using-php-and-javascript/ . In a nutshell you just open the link in a popup using javascript, and then close the window when the user accepts the permissions and make sure the parent window gets redirected.
I ended up using FB.signup from the JavaScript API, mush simpler to use. The only down side is that you get a short-lived token( 2 hours) and opposed to longed-lived token(60 days). But you can always exchange the short lived for a long lived - https://developers.facebook.com/roadmap/offline-access-removal/#extend_token
I have a facebook Iframe application with multiple PHP pages in it.
I have some links that point relatively to the files inside my "iframe folder".
Having some issues with session variables inside the iframe. I set some session variables but they do not persist from one page to another.
This does work on other browsers.
I've been reading that Safari does not support Cross-Domain cookies and this might be the problem , but im not sure how to fix this.
Any help?
I believe this solution has become obsolete with the latest (6.0 and later) versions of Safari.
Safari by default does not allow cookies to be set from third parties. This affects Facebook iframe applications because the user is accessing a page served from apps.facebook.com but the iframe is being served from yourdomain.com, the "third party" in this case.
There are several several solutions mentioned around the web. The best I've found and one recommended by Facebook in its list of miscellaneous issues is to fake a POST request to yourdomain.com using JQuery. This solution detailed by Anant Garg works in general for different host/iframe domains and needs to be adapted for Facebook apps. The key parts are:
$("body").append('
<iframe id="sessionframe" name="sessionframe" onload="submitSessionForm()" src="http://www.yourdomain.com/blank.php" style="display:none;"></iframe>
<form id="sessionform" enctype="application/x-www-form-urlencoded"
action="http://www.yourdomain.com/startsession.php"
target="sessionframe" method="post"></form>');
var firstTimeSession = 0;
function submitSessionForm() {
if (firstTimeSession == 0) {
firstTimeSession = 1;
$("#sessionform").submit();
}
}
Another solution by Will Henderson is to instrument each link on your page with session information using a Javascript function. Then modify your server code to capture this session information by reading it from GET parameters.
I wrote the blog post Dominic refers to in his answer.
The problem is that the default behavior of Safari is to only accept cookies from sites that you visit. This excludes "third party" cookies. Safari treats the page inside an IFRAME as a third-party site, and until you interact with that content (by clicking a link, for example), it will refuse those cookies.
Your PHP code needs to set a cookie on the first page that uses the session in order for that session to persist from one page to another, but if the session variables are in the very first page in the IFRAME, you have a chicken-and-egg problem.
My solution is to retain all of the special Facebook parameters through to the second page loaded into the IFRAME. Because you've interacted with it, cookies set on the second page will persist, and this allows your PHP code to keep whatever state it needs to communicate back to Facebook.
This won't likely help your PHP session, though, so I suggest adding another parameter to links on the first page that allows the second page to look the session up, or otherwise recreate it.
I think the best solution is to manually keep track of the session ID i.e. by using session_id($_GET['session]); Just make sure you do this before calling session_start(); and everything works.
Safari accepts cookies only from the page the user navigates to. The easiest and most effective way to fix this is to redirect the request from landing page of your canvas app to a different page on your domain using top.location.href and redirect the user back to the canvas app from that page.
For example, if abc.php is your landing page and the canvas URL is facebook.com/abc. First redirect the request from abc.php to a different page like xyz.php then redirect again from xyz.php to facebook.com/abc. Don't forget to start the session in xyz.php.
This is the simple fix...
and thanks for all the input. I ended up solving the problem by appending the "signed_request" paramter on every page. I just put it in as a hidden field and set it in the code behind. That way I managed to get it to work in Safari. Hope it works for you too.
With the release of Safari 7, not only 3rd Party cookie is being blocked. Local Storage as well as WebDB, any kind of website data are being blocked. When you go to Safari Preferences (CMD+comma), Under privacy tab, on Safari 7, it now says : "Block cookies and other website", originally was "Block cookies". That confirms the changes.
Other browsers might follow through in the future. Most probably Firefox. Chrome, cough *cough* probably not.
You probably have to employ some workaround using redirection technique or popup similar to what disqus did.
If you using .NET then there is a much simpler solution to this problem.
Just set cookieless to false in your web.config. Ex:
sessionState mode="InProc" cookieless="true" timeout="60"
Its a lot easier than posting an iframe, or opening a popup window with the url of the iframe.
kind regards,
David
I used this header with PHP, that fix my problems
if ( strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE') ) header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');