I'm not sure how to make this question reproducible because it requires having a Vimeo paid (or on a free trial) account.
Vimeo recently changed their UI for creators and made it harder to access one of the pages I use every day.
From https://vimeo.com/manage/videos there is a table with links to individual videos. The URL for each link is something like https://vimeo.com/55555555555555/settings.
If you click, it sends you to Page A: https://vimeo.com/manage/videos/55555555555555.
Then, there's a button that sends you to the page I actually need (Page B): https://vimeo.com/manage/55555555555555/general.
The problem is that when I enter the URL for Page B directly in my browser, it redirects me back to Page A.
Strangely, the back/forward buttons navigate between pages A and B, and the refresh button also stays in Page B. But if I copy Page B's URL, open a new tab and paste it, it sends me back to Page A.
To figure out what's going on, I looked in the network tab of the Chrome Developer tools and found that the first request from Page A to page B looks like this:
But then, if I paste that URL in a different tab, I get a 302:
I've diffed both requests:
Is there a way to prevent the 302 behavior?
I don't have a vimeo account and thus can not test it. Ultimately, the server could use any parts of the diff, but I'd expect it to use the referrer.
Does the page always direct you back if you completely disable setting the referrer in Chrome? If so, using a plugin to forge your referrer could solve the issue.
Unlike 301 redirects which are permanent, 302 are not. The web server displaying 302 errors should redirect the browser and take you to the new location immediately. It should be noted that HTTP 302 status code is due to the web server and not the web browser. There is no control at your end.
Related
I am currently redirecting a website to another new website. My question is does a redirect automatically move my metadata (titles, taglines, meta description, focus keyphrases) to the new site? or Do I have to manually copy and paste metadata to the new site?
Better put - do my rankings from the old site as a result of metadata automatically point to my new site upon redirecting?
Thanks.
You are going to want to look into using a specific kind of redirect, which is the HTTP 301 redirect. That status code means its a permanent redirect, and most search engines will recognize that and will help keep your SEO.
If you do a HTTP 302 redirect, this being known as a temporary redirect, will technically be considered a new URL in the eyes of a search engine.
So when you are testing you redirect, make sure you open up Chrome Dev Tools (F12) and click the network tab. Refresh the page and click the first row that appears in the table. It should specify the HTTP status code, most likely being 200 (status ok), (301/302) permanent/temporary redirect, (404) file not found, 500 (server error).
So essentially, make sure your redirect is using a 301 redirect, if it is permanent of course!
I am working on web app in OutSystems 10.0. In the application, if I log out, it logs off. But when I click the browser back Button, it redirects to the Previous page (which should be displayed only after login). Any suggestions?
You probably need to have roles on the pages, if the pages have the role anonymous anyone can open it.
You're probably accessing the website via http and not https, so when you press back on the browser it will show you a cached version of the previous page.
Because it's the cached version, the session and roles are not checked.
As a recommendation, force the https protocol.
Following the link provided by #Abdulhakeem, they recommend the following:
Add a hidden input to the page - initialize it to some value (for example 'no') - so when the page is rendered by the server it always has a 'no'
Add a bit of Javascript to the page ready event to:
Check that value - if it's not what you'd expect from the server (in our case, <> 'no'), force refresh the page (see below)
If it is still set to what you'd expect from the server, change it (in our case to 'yes') and do nothing else
I recommend downloading the .oml provided in the post and reviewing how they actually implemented it.
if you can change to https, you can also in every action that is on the page that do changes on the database. check if you have permissions or you are logged. that way if the person tries to do back and do some action you can redirect it somewhere.
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!
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.
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.