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.
Related
I have a problem with facebook login on Presta Shop. I am using TemplateMonster Social login plugin (tmsociallogin). It worked a few months ago but now it stopped. I am receiveng error:
"Can't Load URL: The domain of this URL isn't included in the app's domains. To be able to load this URL, add all domains and subdomains of your app to the App Domains field in your app settings."
Urls and paths are set correctly in apps settings I think (correct domain, correct redirect URL, correct app domain). You can see my setting on screen shots below.
I have found a lot of answers but everywhere I've seen that I have to uncheck "Use Strict Mode for Redirect URIs" in fb app settings. I cant do that - this option is hardly checked as "Yes" and I can not do anything about that.
Please anybody help me :( Prestashop version 1.6
Apps settings 1
Apps settings 2
Facebook error
It happens because Facebook has changed a security policy and forbidden to use nonstrict mode for a redirect. But the module was using this option to redirect to the same page after login. So now it causes the issue. In order to solve this, you need to remove all mentions about a "back" parameter within all files which are related to Facebook login functionality. I don't know exactly your version of the module but I think the list of files will be the same
controllers/facebooklogin.php
controllers/facebookregistration.php
views/templates/hook/header-account.tpl
views/templates/hook/social-login-buttons.tpl
In the *.tpl files remove only that entities which are related to facebook.
And in your Facebook API you must to add two redirect URLs.:
Whether you use Friendly URL
- your_domain/module/tmsociallogin/facebooklink
- your_domain/module/tmsociallogin/facebooklogin
or not
- your_domain/index.php?fc=module&module=tmsociallogin&controller=facebooklogin
- your_domain/index.php?fc=module&module=tmsociallogin&controller=facebooklink
Also, if you aren't sure yet which mode are you gonna use then you can add all four variants.
I created the simplest app ever - I basically just want to iframe my website paleoitforward.com.
>> Here is a screenshot of my app settings
However, I get an error message on the page. You can see it in action here:
http://facebook.com/heathercashart/app_337591392998654
In Chrome, I get the message "This webpage is not available"
In Firefox, I get the message "Firefox can't establish a connection to the server at localhost."
Localhost... how weird?
I can't figure out why it won't load, and I'm not sure how to troubleshoot it :-/
The site loads over HTTPS fine, so HTTPS is not the problem.
Also - FYI - I am a n00b at this Facebook app stuffs... :)
Thanks,
Heather
Ok, I am not exactly sure what fixed this, but I was basically just messing around changing the URL's (adding http, removing http, adding trailing slash, removing it...) and all of a sudden it worked!
Here are the URLs I used that ended up working in case anyone has this problem in the future (make sure you pay close attention to http/https and trailing slashes!):
App domains: paleoitforward.com
Website with Facebook Login
Site URL: http://paleoitforward.com
Page Tab
Page Tab URL: https://paleoitforward.com
Secure Page Tab URL: https://paleoitfoward.com/
Page Tab Edit URL: https://paleoitfoward.com/
In your app settings (the screenshot shows it) you wrote paleoitfoward.com in your page tab settings – missing the R in foRRRRRRRRRRward …
Live is easier if one can read, believe you me :-)
I have just migrated a site to a new domain (with new design) and am redirecting from the old site to the new with .htaccess and redirect 301. Since the new site is quite different, I'm concerned that users might be disoriented. Is there a way to have a popup on the new site that users get only if they have been redirected from the old site? Have been searching on this but keywords seem to lead only to stuff on popup redirects to another site.
I can think of several ways to do it:
Redirect in the 301 to another page (www.blah.com/tour instead of www.blah.com) and there i would put the logic to show the popup
Redirect in the 301 to another page and there set a cookie and redirect to the original page. Then, add logic to the original page to show the popup if the cookie is present (and delete the cookie)
Check the referrer in the new site and if it matches the old one, show the popup
Your problem boils down to detecting a request that has come via a 301 redirect - popups and usability are a separate (simpler?!) issue.
Unfortunately, detecting a 301 redirect is one of those inexact things that requires a mixture of techniques to get near to 100%. I say near, but never quite there - a bit like browser detection.
One option is to append a querystring (GET) parameter to the redirected URL, e.g.
www.example.com/LandingPage.html?isRedirected=true
You could also set the same info in a cookie (but won't work if cookies are disabled or cleared).
Another option is checking the Referrer header - but again, these may differ based on browser implementation and can be faked, although if someone's faking a redirect I don't think you need to worry about guiding them through your new design!
Problem
I have an application driving a tab on a client's page. The application works correctly if the user has not enabled FB's "secure browsing" feature. If attempting to view over HTTPS, the iframe doesn't even appear (no errors, no mixed-content warnings). When correctly loading over HTTP, the div with the id "pagelet_app_runner" has an iframe inserted into it and the application content is loaded inside there. Over HTTPS, this div remains empty and the iframe is not inserted into the page. There are no Javascript errors appearing in Firebug or Chrome's equivalent console.
Why I'm Asking Here
The host has a valid SSL certificate and there is no 'mixed content' at the URL in question. I can successfully view the content over HTTP or HTTPS by visiting the URL directly, and I can do the same by visiting apps.facebook.com/canvasURL/tabURL. It is only when attempting to view within a Page Tab that the HTTPS load fails as described above. My application is configured with both regular and secure canvas and tab URLs.
Attempted Debugging
I've recorded some sessions with Charles but since the iframe isn't being inserted into the page, I think I'm coming at the problem after it's already occured. I'm no Charles expert so happy to be corrected here.
Apache isn't seeing any request (in either regular or ssl logs) for the affected loads. non-SSL loads come through as expected in access_log.
Plea for Help
I'm out of ideas for debugging this. Does anybody have any suggestions? What really obvious and stupid mistake might I have made? :)
edit: nicer formatting
Your app canvas URL is https://skinnycomp.nextstudio.com.au/skinnycowcomps/ , which send 404 error to Facebook proxy (request is going through proxy when viewing app via tab), also when viewing your app via apps (https://apps.facebook.com/122381834451561/), again 404... maybe Facebook proxy is ignoring 404 and posting blank...
Try changing canvas URL to https://skinnycomp.nextstudio.com.au/skinnycowcomps/tab, also you can check if your app is accessed via page tab, in signed_request there should be page_id...
23:51:15.379[549ms][total 1667ms] Status: 404[Not Found]
GET https://skinnycomp.nextstudio.com.au/skinnycowcomps/
This is a real longshot since I'm sure you've triple checked all the settings, but the blank page can happen if an invalid url is specified in the Page Tab URL field in the app settings. Since it only happens on https, it would imply something specifically with the Secure Page Tab URL entry. It might be worth checking that again, and maybe even re-saving it or changing it to something else to see if it helps.
I was using relative URLs for the regular and secure tab URL fields. From memory relative URLs here were mandatory at some point in the past. It appears now that a relative URL will still work for HTTP but not for HTTPs. Fix: absolute URLs. Hopefully FB update their field validation to match what's required too.
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"');