our fangate is working perfectly here in our office on safari, chrome or firefox,
but OF COURSE, not on the customers computer, neither chrome nor firefox nor safari.
So we looked via teamviewer whats going on in his environment, and we saw in firebug
that facebook is going to fire a post after the click on "like" which results in "404"
http://www.facebook.com/ajax/pages/fetch_app_column.php?__a=1&__user=XXX&fb_dtsg=AQBzGDeE&phstamp=165816612271681016991&profile_id=XXX&tab_key=app_XXX
Did anyone encoutered this problem?
In my experience, bugs like these crop up often with Facebook and to make things worse they exist for days at a time on some or all of their servers, this means that some users get errors and some it works fine for.
Recently we have seen this fangate issue for a number of days before they fixed it. If you can't find the bug listed on their systems I would register it as soon as possible. http://bugs.developers.facebook.net/
Related
The site of the company I work at is using a Consent Management Platform which was functioning ok. Lately, we had to make some modifications in it and had to reimplement it. The implementation went ok, even the engineers who offer support for the CMP I'm using confirmed that everything I did was fine.
And now the problem: some users are still having the old cookie on their devices. So now when they are entering the site they receive a 400 error and can not access the site anymore. The fix would be so that every user manually deletes the cookie on their device but this is impossible to do as our visitors are not very technical and we can't reach all of them.
So, is there anyway to somehow make any kind of change/implementation, from our side, from the server-side, in order to refresh the users session and make their 400 error disappear without them having to do it manually?
I'm really in a pinch right now and am in need of real advice.
I'm receiving reports of several users running into issues with a django-registration sign up flow. I'm not able to reproduce it, and I believe it's just happening for certain browsers.
The problem happens when they follow the email activation link. Although the database shows they have successfully activated their email, they see the page that says that the link has expired. It's as if they visited the activation page already and then are seeing it for the second time. Initially I thought this was user error, but several users have reported it, which makes me think there is something else up.
One user has reported it working in Firefox, but not Safari, on a desktop - and not working on iPad or iPhone.
I have used django-registration a lot so I'm surprised by this bug and am drawing blanks about what it might be down to. Anyone have any ideas?
PS This is also happening with the same site, perhaps related: Django messages faulty, but only on one particular network
I have a website that is being used by various corporate employees. Just today I have a user saying that everytime they login (even with correct username and password), they get an error saying they have to login to view the page. Basically, they type the right username/password and get forwarded to the home page, but that controller has a login required decorator which rejects them and they get sent back to the login screen. The user tried in IE10 and Google Chrome web browsers.
I have not been able to replicate this issue anywhere and unfortunately, i'm in no position to really ask this user for more information for debugging purposes :(. Has anybody seen this before??
I tried googling this, and i'm seeing issues with Django for IE but nothing with Chrome. Is there anything else that could be happening?
I'm using nginx+uwsgi on the server if that makes any difference.
Without more information this is pretty much impossible to solve.
Because no one else is having the problem and you can't reproduce it, I'm inclined to believe it's user error.
Have them clear their cache/cookies (The fact that it's multi-browser is troubling though), see if that helps.
Best guess so far without more information: The user has cookies disabled. I think Django auth relies on cookies.
Using of mobile dialog authentication is working well for other mobile devices except on this Nokia N70.
1) I call to graph api
https://graph.facebook.com/oauth/authorize?type=user_agent&display=wap&client_id=xxxx&redirect_uri=xxxx&scope=user_photos,read_stream
2) which make for mobile devices to display the below uri
https://m.facebook.com/dialog/permissions.request?_path=permissions.request&app_id=xxx&redirect_uri=xxxx&display=wap&type=user_agent&xxx
But, it can't display the 2) step dialog and automatically redirected to my redirect_uri which gave me errors of 404. Actually it show display authentication dialog box and should get grant from User.
What exactly might be the issue?
While I can't find specific information on why it wouldn't work I would most likely suspect that because the N70 is a 6 year old phone and uses WAP 2.0, which Facebook actually hardly supports anymore as stated in numerous places. (e.g. Facebook Feed Dialog Mobile Url: Issue with display=wap
All modern handsets support full HTML these days. So WAP is mostly dead besides people who haven't updated their handsets in the last 3-4 years.
My suggestion is, why are you hoping to support WAP and is it really needed?
UPDATE [2012-07-07]: Facebook is now removing display=wap, hence making it completely dead in Facebook's world.
I have a strange issue here with my Django app. I implemented the user auth/profiles, and I can log in successfully, etc, with various computers and from three different internet locations. It all works, except for this one computer.
This one computer receives this error when they log in.
CSRF verification failed. Request aborted.
No CSRF or session cookie.
I tried testing various browsers on this one computer, all get the same error. I even tested logging in on another computer from the same internet, and it works just fine. I believe this test reveals that it is not an internet problem, and it is a general computer setting problem (not specific browser).
I'm afraid that if this error happens with this one computer, if I go live, there may be other computers out there with the same issue. Is there anything I can do to check to see why it is happening only on this one machine, and more importantly, how I would fix it?
I'm hosting the app on some computer using the Django dev server.
Thanks a lot.
It could be that the error is misleading. When I have seen a problem with logins for applications that impact only one computer, but multiple browsers, it has usually been a problem with the date that computer is set to interacting with expiring cookies.
For example, this one computer may be set with a date 1 month into the future and the cookie being sent is being expired instantly because it is only a 90 minute session cookie.
So while it's not even really a Django related answer, check the clock on that computer. :-)