Does anyone have an idea why amfphp might consistently return 403 errors for a particular machine while all other machines work fine?
Here's the deal: I have a site that pulls its content from a Drupal backend via Drupal's Services module. All but one of the 15+ machines I've tested on perform fine. The call is made, the data returned, etc. However... this one machine - which as far as I can tell is no different than the other OSX/FF2 combos in the testing pool - consistently gets hit with a big fat 403. Login state for the CMS at the time the call is made does not affect the result.
Thoughts? Suggestions? Condemnations?
have you looked at: http://www.yourUrl.com/amfphp/browser
and run your service from the flex app thing?
you shoudl be able to test your service there and get results with out the app, and determine if its a flash gateway or responder problem or the service itself...
I think this goes over it somewhere in the video if you have not used it before...
works for amfphp 1.9 beta...
cheers
Something magical must have happened overnight because now it works. No idea what it was. :shrug:
:: performs magic under shade of night ::
glad it's sorted!!!!
my guess would be a corrupted cookie somewhere and the cookie was expired and replaced by firefox the next day. ???
weird one.
Thanks, all.
From someone in-the-know:
Never seen anything like this one. The only thing I notice is that in that Firebug screen shot the user has a cookie (which means they had logged in to the Drupal side) and the cookie differed from mine in that mine ends with has_js =1: SESS21ad7b3803ea77a024a840c5c00824f2=nc268rosrpiebk89jjn988e6b0; has_js=1
Yet clearly the person has javascript turned on if they are seeing the flash site at all. I'm trying to reproduce the problem by logging into the Drupal site without js enabled, then enabling js to see the flash with the non-js cookie, but haven't been able to reproduce so far.
Maybe have them try clearing their cookies and cache as a start? It doesn't make much sense because the problem appears to be server-side yet is somehow user-specific. My hope is that they got something screwy in their cache during development. Sometimes a 403 could maybe be stuck in a cache after the problem is resolved.
My thinking is that the magical resolution was actually a product of our guy simply emptying his cache. He swears that wasn't it, but he's probably just afraid of what I'll do should I find that I wasted a whole Sunday on this for nothing. 
Should ask him if he has an adblocker, popup blocker or safe web surfing ware.
These often disable certain javascript functions on the initial page visit, but not all, and present a popup asking you if you'd like to grant the page permission in their own ui. The page then fires page and document things like onload. If the JS on the site requires things fire in a specific sequence, sometimes onload runs far to late, in this case after a cookie has been set.
I ran into this while working on a popular clothing website. A cookie would get set before the user allowed onload to run. I changed the way the site was loaded so that it didn't do that.
So the problem may still exist.
Duly noted. Thanks.