Access Denied from aweber redirect - redirect

One of my pages in my domain is set up as a redirect from aweber, so when I confirm on the link on an email optin from aweber it redirects to this page MyPage.html and includes a welcome message with the name I signed up with.
Now granted I am not sure if this is something to do with aweber set up for redirect although it's very easy to do (basically paste the URL in settings you want to redirect to) and I have double/triple checked it. I also contacted aweber support who said it can be the javascript for personalisation embedded in the Head section of the redirect page that can cause this error. I have removed this code and can confirm it is not the javascript or redirect causing it hence my appearance here.
I also have another portion of the site using this redirect and personalisation and it works fine.
Now when I click on the link in my email from aweber it gives me this error:
Forbidden
You don't have permission to access /mypage.html on this server.
Additionally, a 500 Internal Server Error error was encountered while trying to use an >ErrorDocument to handle the request.
And the redirect URL is below so I can see it is redirecting with my details ok but failing to give me access to the page.
mysite.com/mypage.html?email=myemail%40yahoo.co.uk&from=myemail%40yahoo.co.uk&meta_adtracking=my_web_site&meta_message=1001&name=MyName&unit=MyAweberListName&add_url=http%3A%2F%2Fwww.MySite.com%2FthankyouPage.html&add_notes=xx.xx.xx.xxx
All my pages have access permission 644 and the page is a copy of one of my other pages, which works fine, I've not added anything, changed anything, only removed text lines and graphics.
I just also tried remaking the landing page and it failed once more. Funnily enough though when I manually type the page into the URL bar up it comes; this worked before with the original page as well!
This works:
mysite.com/mypage.html
This [redirect] doesn't and gives the error described above
mysite.com/mypage.html?email=myemail%40yahoo.co.uk&from=myemail%40yahoo.co.uk&meta_adtracking=my_web_site&meta_message=1001&name=MyName&unit=MyAweberListName&add_url=http%3A%2F%2Fwww.MySite.com%2FthankyouPage.html&add_notes=xx.xx.xx.xxx
Any ideas on getting to the bottom of this would be greatly appreciated.
Host is hostgator

Related

Redirects in Ektron 8.6.1

Has anyone played with the new redirect feature in Ektron 8.6?
We tested it (in 8.6.0) before upgrading and were happy with it. But when it came time to do the upgrade, Ektron had released 8.6.1, so we upgraded directly to that.
Now we are having trouble with the redirect feature. (Yes, we should have tested everything again in 8.6.1 before upgrading)
Now if we try to add a redirect rule for an existing page in the CMS, it does not work.
But if we create a redirect rule for a page the does not exist, then try to hit that address, the redirect works fine.
We need the redirects to work for existing pages in the CMS.
To clarify what "working" and "not working" means...
If I have an existing page in the CMS with manual alias of "/erc/lucien.apsx", I can create an entry in the redirect table like this...
Adding this entry generates no errors, but when I visit the page, all I see is the regular old page I created. NOT the Google site it should be redirecting to. I do not get any 404 errors.
But if I create a redirect entry for a page that does not already exist, like this...
It works perfectly. If I try to visit the /erc/fake.apsx address, I end up on the Google site, as expected.
(FYI, we create a "fake" page in the CMS for external content so we can attach metadata to it and make it searchable in taxonomies, but then provide a link to the "real" page. I want to use redirects here so users don't have to do this extra click)
I suspect it might be cache related -- the original URL gets cached as an alias, then subsequent requests to that URL are redirected to the quicklink without the need for a db look up. When you add the redirect, it’s probably not clearing the old item from the cache. I'd try an IIS reset after you add the URL redirect and see if that clears up the issue.
An "outside the box" (of Ektron) answer to this is to place the redirect at the web server rather than in the Aliases section of the Ektron CMS.
The server I work on uses IIS and I have this set up for several pages.

URLs redirect to spyware site

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.

Facebook Send Dialog fails to send links to Facebook itself -- why?

I'm trying to use Facebook Send Dialog in a WinForms frame with a browser control and direct URI (you can repro just by clicking the links below). It works fine with link=http://www.foo.com, sending the message properly if you enter a message and click "Send":
http://www.facebook.com/dialog/send?app_id=179873125388138&link=http://www.foo.com&redirect_uri=http://jonnewman.com/&display=popup&to=100002395463043
However, this fails with link=http://www.facebook.com or any path under it. Clicking "Send" just gets you "Sorry, something went wrong. We're working on getting this fixed as soon as we can.":
http://www.facebook.com/dialog/send?app_id=179873125388138&link=http://www.facebook.com&redirect_uri=http://jonnewman.com/&display=popup&to=100002395463043
The aim is to write a script to make it easier to send messages asking all users in a particular group to a page (prepopulating the recipient list). Since Facebook has restricted groups larger than 500 members, our organization has to move to a Facebook Page, and I want the Send Dialog to link the new Facebook Page. Why won't this work? Is there a workaround? Are there other criteria for what links Send Dialog will and won't send?
Also, is there a way I can determine whether the send occurred or not, for example an event to catch? Whether you send or cancel, the Navigated event is still redirect_uri/#_=_.
Once I have Send Dialog working, I will add Show-FBSendDialog to Facebook PowerShell Module, which already has numerous capabilities to automate Facebook from PowerShell.
ran some tests and it seems it is blocking any fb domain http://on.fb.me/91S2P8, sometimes this is temporary otherwise need to rethink...
I see your second link isn't working... but if you add your company page id or name to link it should work. following link works for me:
https://www.facebook.com/dialog/send?app_id=179873125388138&link=http://www.facebook.com/Intel&redirect_uri=http%3A%2F%2Fjonnewman.com%2F&display=popup&to=100002395463043
hope this helps
I got solution. I also had same problem. No post helped me. Solving error for 2 days.
There were posibility of two mistakes(that was done by me).
Link Parameter given in url should be working. I have linked to api namespace but not given SSL url. So it was giving problem. You can given your web site address.
And redirect_uri parameter should be working. Try to give redirect_uri to same page most probably.

Silent failure loading page application in iframe over https

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.

Workaround: site is www.example.com code incl. document.domain='example.com'

A customer site that I cannot change has the line document.domain = "example.com" while the site is at www.example.com.
The effect is that FaceBook Connect window login gets stuck after submitting username+password.
Firebug shows its in infinite loop inside dispatchmessage function, which gives perpetual exception:
Error: Permission denied for <http://www.example.com> to get property Window.FB from <http://example.com>
Any idea how to work around this? I prefer not to ask the customer to remove the document.domain='example.com'
It seems like a really bad idea to tell the visitor's browser that the website is being served from a particular domain, when it in fact is not. The best solution would be to change that line. I take it you don't want to change it because they have some client-side code that depends on this?
One workaround would be to change the Facebook application's Connect URL to http://example.com, since Facebook's JavaScript will think that is where it is being executed.