Most people who are trying to login with Facebook are having no trouble, but about 5% of people who try to sign up are unable to. I believe the issue is due to some people not having certain information in the response that I get back from Facebook. Why do some people not have email and location in their response even if I have requested the email and user_location permissions?
I looked at your javascript and saw a couple of things you should check into:
When you initialize the javascript SDK you set cookie=false and status=false. Most examples I've seen set these to true. This might not have anything to do with the 5% exceptions you are seeing, but I don't see how it would hurt to set them to true, and it might help. Give it a try and see if it makes a difference.
The bigger issue I see is your code is assuming that the permissions are granted. You really need to check the response object in the callback to FB.login. The user might not have logged in, and they might have denied some of the permissions. You need to check the response object to see if it has an error in it.
You will need to query the permissions table (fql) or do a get to /me/permissions to know what permissions they granted. It would be nice if the FB.login callback response object told you what was granted vs. denied, but it doesn't.
Also I believe there are cases where people don't have an email registered with Facebook or a location.
To summarize: you cannot trust that you will get what you ask for, you need to check the response object and handle the exceptions gracefully, reprompting for authentication with a message indicating why you are re-prompting.
Another thing you might want to consider adding is a client-side logging tool such as log4javascript (or roll your own) that gathers more information about these exceptions. There may be a pattern for example a specific browser that is not handling things well.
Related
EDIT 1
One thing I didn't make clear in my use case was that the browser DOES NOT need to show the UX to authenticate, or at least it's optional.
var credential = await navigator.credentials.get({
password: true,
mediation: "silent",
federated: {providers: federatedProviderURL}}
);
If the user has logged off or removed passwords from the UA then it will fail (credential == null).
The credential spec writers may stipulate that, if called from ServiceWorker, mediation must be "silent" or, if otherwise and no UI available an: -
Error - NOUI Action requires UI to complete
But the important point here is in the vast majority of cases keyless re-authentication can take place.
Does that change things at all?
Cheers Richard
ORIGINAL POST: -
If a Fetch in my ServiceWorker receives a 401 from the server how do I re-authenticate with the server if I have no focused or foregrounded client?
NB: I'm talking about POST requests updating the server and not just reading from cache until the network is back.
Bring the client back into focus? Scary for user with no action causing that reaction and they may not be there to login again anyway.
What does Background-Synch do if it gets a 401?
If navigator.credentials was surfaced in a ServiceWorker that would be enough!
Sessions that never expire?
What are other people doing?
Yet again I'm banned from W3C/IETF Github :-(
If someone could add the following to ServiceWorker issues that would help: -
Please see Use-Case
If a User Session has expired a ServiceWorker currently has no mechanisms available to re-authenticate with the server as there is no heuristic mechanism available for determining credentials.
If the credentials.get() was available then re-authentication could take place transparently. If federated (say Google) then if the user had logged out then that state would be honoured.
It seems there has been discussion on this before. Please see GitHub
I think that background re-authenticating should be infrequent enough that a notification of the sign-in or failure is an appropriate and user-friendly solution.
Please comment over there if you have any ideas!
I have what I'm sure will be a very easy question, I'm just confused.
I have successfully got my server subscribed, for real time user/feed but simply am not getting any updates.
I have logged myself in using the FB.login JavaScript SDK, using the scope "user_about_me,user_status,read_stream" - so I expected to see updates for my user, but not getting anything at all.
The app is in "Development Mode", so, can anyone confirm that since I have got a { success: true }, that the reason is simply because of this? Or perhaps I need to put it under review from Facebook?
Thanks.
Woo, it's fixed now!
On my research, I had come across this post:
How to subscribe to real-time updates for a Facebook page's wall
Not realizing that I can use the USER_ID in place of the PAGE_ID. Following the Real Time Subscription documentation, I thought that by using the APP_ID, that it would allow to make one subscription for all users that grant the application its scope.
On to the next hurdle...
I've seen a few people having problems with the oAuth1.0 using hello.js with Twitter, LinkedIn etc. Unfortunately, I am one of them. Trying everything I can to fix it, but I need help.
To explain:
I have my Twitter credentials initialised:
hello.init({
'twitter' : '*******************'
},
{
redirect_uri:'****************',
oauth_proxy: 'https://auth-server.herokuapp.com/proxy'
});
(I presume that the 'oauth_proxy' in my case here is correct?)
Apart from that, I have tried calling the function in the button tag like so:
onclick="hello.login('twitter');">
I have seen people making errors having skipped the 'https://auth-server.herokuapp.com/#signin' step but I have all my credentials inputted there for the mean time. But, one question:
The 'Reference' section, is that just a nickname kind of thing? And what's the 'Domain' section about?
The error that I'm receiving is a 401 error message.
Another question:
Do I need all of the 'twitter.js' & 'client_id.js', or is including 'hello.js' sufficient?
I appreciate any effort to help me with this. Thank you.
As Andrew said (after all, he is the one who wrote hello.js), one of the problems could be related to the callback URL. I found out after a while that Twitter (unlike Facebook) does not accept 'localhost', so instead one has to write 127.0.0.1.
That solved all my problem when being stuck at the same point.
So yes, the reference is a nickname e.g. "dropbox", and the domain field is the domains e.g. "myapp.com". Its advised to fill both these in for your own reference and their misconfiguration wont lead to a 401.
The 401 is likely that your client id / secret is incorrect. Or the redirect_uri defined in hello.init does not match the Callback URL you assigned to that client id when you registered with a third party service.
The error handler hello(network).login().then(successHandler, errorHandler) should give more information. Can you attach that too your question?
"client_id.js" is a demo script which defines the credentials used for my hellojs demos. Do not include it!
However you may like this approach for maintaining your application credentials in a separate file - this approach is left up to you.
All you need to include to get started is dist/hello.all.js this contains hello js and all the third party configurations listed.
How should I design an on-login middleware that checks if the recurring subscription has failed ? I know that Stripe fires events when things happen, and that the best practice is webhooks. The problem is, I can't use webhooks in the current implementation, so I have to check when the user logs in.
The Right Answer:
As you're already aware, webhooks.
I'm not sure what you're doing that webhooks aren't an option in the current implementation: they're just a POST to a publicly-available URL, the same as any end-user request. If you can implement anything else in Node, you can implement webhook support.
Implementing webhooks is not an all-or-nothing proposition; if you only want to track delinquent payments, you only have to implement processing for one webhook event.
The This Has To Work Right Now, Customer Experience Be Damned Answer:
A retrieved Stripe Customer object contains a delinquent field. This field will be set to true if the latest invoice charge has failed.
N.B. This call may take several seconds—sometimes into the double digits—to complete, during which time your site will appear to have ceased functioning to your users. If you have a large userbase or short login sessions, you may also exceed your Stripe API rate limit.
I actually wrote the Stripe support team an email complaining about this issue (the need to loop through every invoice or customer if you're trying to pull out delinquent entries) and it appears that you can actually do this without webhooks or wasteful loops... it's just that the filtering functionality is undocumented. The current documentation shows that you can only modify queries of customers or invoices by count, created (date), and offset... but if you pass in other parameters the Stripe API will actually try to understand the query, so the cURL request:
https://api.stripe.com/v1/invoices?closed=false&count=100&offset=0
will look for only open invoices.... you can also pass a delinquent=true parameter in when looking for delinquent customers. I've only tested this in PHP, so returning delinquent customers looks like this:
Stripe_Customer::all(array(
"delinquent" => true
));
But I believe this should work in Node.js:
stripe.customers.list(
{delinquent:true},
function(err, customers) {
// asynchronously called
});
The big caveat here is that because this filtering is undocumented it could be changed without notice... but given how obvious the approach is, I'd guess that it's pretty safe.
I am currently working on a small private project which allows me to upload pictures to a website. A feature which I want to implement is to allow visitors to easily add the images to their Dropbox.
Because this is only a minor feature, I do not wish to implement the full-blown Dropbox-API, and after a bit of research I found the Dropbox Drop-Ins, which seem to be exactly what I was looking for.
I have implemented this after the instructions from the Dropbox-Site: https://www.dropbox.com/developers/dropins/saver#javascript
I use the following code to add my images to the Dropbox:
Dropbox.save({
files: dbFiles,
success: function() {dropboxSuccess();},
progress: function(progress) {dropboxProgress(progress);},
cancel: function() {dropboxCancel();},
error: function(errmsg) {dropboxError(errmsg);}
});
where dbFiles is a simple array with the neccessary objects.
Basically, I think that it is working: A popup appears where I have to login or, if I'm logged in, choose a location in my Dropbox to add the pictures.
However, the following error gets thrown shortly after:
"Received non-200 response status 503 from server"
This is all information that is returned!
I have tried a lot of things, but nothings helps.
Here is the page where I implemented it:
http://thetrip.fnovy.com/dropbox.php
Errors get logged to the console.
I couldn't find any information regarding errors for this Drop-Ins, neither at the Dropbox-Site nor via search engines.
Double-check your URLs and how they're being redirected. For example, the first URL on your page, http://phototrip.fnovy.com/uploads/images/2013-08-12_Test_File.png, is responding with a 302 redirect to http://phototrip.fnovy.comuploads/images/2013-08-12_Test_File.png, which is, naturally, not resolving. :-)
I believe that the 503 is a somewhat misleading interpretation of the real problem, which is that the domain doesn't resolve. I'll update this answer if I learn more about that.
EDIT Confirmed that you see a 503 when the domain doesn't exist. We may be able to give a clearer error message for that, and I also hope we can give the URL in the error message so it's easier to see which URL is causing the problem. Thanks for pointing this out.