When a user registers on my system, I create the user internally, and then allow the user to register with Firebase using the firebase client lib. This generates a session token for the user. Later, when a user starts the app again, the app automatically logs the user in like this:
ref.authWithCustomToken(sessionToken, function(error, authData) {...
debugger
I have verified that the sessionToken is available when the function is executed, but debugger is never reached, and no error is ever emitted.
Any help is appreciated!
I know it's a bit late, but I experienced a similar problem and it had me scratching my head for a while, so just in case it helps somebody else, here's what I found.
If I run authWithCustomToken with a token generated with one uid (uid1) and then run it again on the same ref with a different uid (uid2), the callback doesn't get fired the second time around.
In my case, I had declared the same ref in different modules that were used in the same node process and was trying to authenticate them with different uids. Although I had declared the ref twice, Firebase still saw it as the same ref because it was in the same process and referred to the same Firebase location. By declaring and authorising the ref in a parent module, I was then able to use onAuth in the child modules and the onAuth callbacks all fired as expected.
I had a similar problem with iOS, authWithCustomToken callback was never called right after install.
All consecutive launches worked fine.
My findings might be related so I thought I share them.
Problem was I called
func applicationWillResignActive(application: UIApplication) {
Firebase.goOffline()
}
func applicationWillEnterForeground(application: UIApplication) {
Firebase.goOnline()
}
in AppDelegate. Turns out if you call Firebase.goOnline() without logging in first it messes up the callback. Once I removed those two lines everything worked fine.
Related
We are using MongoDB Realm in our app.
The first time the user is connected to the app, the ProgressNotifcation callback is triggered correctly, and it will work and trigger whenever a new download is coming.
Even if no download is pending, the ProgressNotification callback will be triggered (the Progress object pass in the callback will contain values from the last download) at least once(when creating it). I supposed this is due to the fact that we are downloading the first data set of the user.
But after killing the app and launching it again, the ProgressNotification callback is not triggered anymore until new data are received by the app. And from this point, the callback will be called every time we need it.
It seems that now, the framework needs a first download since the app is launch to make ProgressNotification callback to be triggered every time we need it.
This was working in the previous version of Realm (5.X.X). We just finished the migration to Realm 10 and discover this issue.
I am a bit stuck here, do not know if this is an intended change or a bug on my part. But I am pretty sure this was working in the previous version of the SDK.
Can anyone help me with this? Thanks
Note: this is no more working in both mode : .forCurrentlyOutstandingWork and .reportIndefinitely
Example
self.token = syncSession.addProgressNotification(for: .download, mode: .forCurrentlyOutstandingWork) { progress in
.......Some code........ <- this part of the code is not triggered anymore
}
EDIT - 21/12/2020
For clarification, the token returned contains a value and the .invalidate is not being called.
There is no error in the session and any new download is triggering the callback. After an initial download, everything works as expected. This means that when I add a progressNotifcation later on, the callback is triggered immediately with the progress of the previous download. But if there is not an initial download, the callback is never called.
For the scope, this method is actually in the custom publisher that I created and it is not deallocated.
Realm 10.5.0
iOS 14.3
Looking for some clarification as to how one can log caught exceptions using flutter's firebase_crashlytics package.
If I understand correctly (and from running some sample code) Crashlytics.instance.log('text'); will only add logs to the next crash report, rather than send off a non-fatal issue itself.
I'm looking for functionality which is equivalent to Crashlytics.logException(e); on Android, e.g.
try {
throwException();
} catch (e) {
Crashlytics.logException(e);
}
which allows you to log caught exceptions so they appear as non-fatal issues in the Crashlytics dashboard.
Is this currently possible with flutter's firebase_crashlytics package?
Is calling Crashlytics.instance.recordError('text', StackTrace.current) the way to achieve this for now?
Many thanks!
Short answer, yes.
Crashlytics.instance.recordError() is the equivalent of Crashlytics.logException()
If you dig into the Flutter firebase_crashlytics source code, you can actually see what Android APIs are involved.
Flutter’s recordError() invokes the method Crashlytics#onError in the Android library.
And tracing Crashlytics#onError, you’ll see that it goes to Crashlytics.logException(exception);
Additional note, you’ll also notice why Crashlytics.instance.log() ”will only add logs to the next crash report”. These logs are added to a ListQueue<String> _logs which is then packaged into the next call of recordError()
A snippet of Flutter’s invocation of Crashlytics.logException():
_recordError(...) {
...
final String result = await channel
.invokeMethod<String>('Crashlytics#onError', <String, dynamic>{
'exception': "${exception.toString()}",
'context': '$context',
'information': _information,
'stackTraceElements': stackTraceElements,
'logs': _logs.toList(),
'keys': _prepareKeys(),
});
}
And some reference notes for Crashlytics.logException():
To reduce your users’ network traffic, Crashlytics batches logged
exceptions together and sends them the next time the app launches.
For any individual app session, only the most recent 8 logged
exceptions are stored.
To add to the accepted answer, Crashlytics.instance.recordError() has now been deprecated for the new method FirebaseCrashlytics.instance.recordError(exception, stack).
BONUS TIP:
I had this problem where all the logged exceptions are grouped under the same issue in Crashlytics dashboard. These might be different crashes of the same or different code components. Due to this, I had to manually go through each instance of the crash to verify.
From my own testing, I found out the grouping is based on the top-most line in the stack trace you passed into the method above. Luckily, Dart has an easy way to get the current stack trace using StackTrace.current.
So to properly group the issues: get the current stack trace at the time of the exception and pass it in FirebaseCrashlytics.instance.recordError(exception, stack).
Hope this helps someone out there, I looked everywhere on the internet for a similar issue but can't find any.
I am using firebase realtime database and I have a multi path firebase update query that I was using for a while, however for last couple of days the callback never fires and other firebase database requests are blocked as well until this one fires. Callback takes incredibly longer to fire than it should or it used to. And most interestingly this issue does happen on Windows environment only.
let updateObj = {}
updateObj[`transcripts/${uid}/${itemId}/currentState`] = currentState
updateObj[`lists/${uid}/${itemId}/edited`] = firebase.database.ServerValue.TIMESTAMP
updateObj[`lists/${uid}/${itemId}/filename`] = title
db.ref().update(updateObj, function(error){
//handle error
}
I thought it could possibly be because another reference is initialized at the same path later on but callback sometimes hangs even before that.
updateObj[`transcripts/${uid}/${itemId}/currentState`] = currentState
variable currentstate above has a somewhat of a big array node inside so I also think the array might be the issue considering they don't really work that efficiently with firebase realtime database.
Commenting this out solves all the problem but I am still clueless how this suddenly started to break firebase realtime database for me.
I am trying to implement some methods for a DDP API, for use with a C# remote client.
Now, I want to be able to track the connection to implement some type of persistent session, to this end, id hope to be able to use the session id given by DDP on connection, example:
{
"msg": "connected",
"session": "CmnXKZ34aqSnEqscR"
}
After reading the documentation, I see that inside meteor methods, I can access the current connection using "this.connection", however, I always get an undefined "this.connection".
Was it removed? If so, how can i access it now?
PS: I dont want to login as a user and access this.userId, since the app I want to create should not login, but actually just get a document id and do work associated with that, including changes to other collections, but all, regarding ONLY this id, and I dont want to have to include this id every time I call a function, since, this could possibly lead security problems if anyone can just send any id. The app would ideally do a simple login, then associate token details with his "session".
Changing from:
() => { this.connection; }
to:
function() { this.connection; }
solves the problem from me. Based on a comment in the accepted answer.
The C# client on github has a few bugs with it as it doesn't follow the DDP spec exactly. When you send commands to it to connect and run a call, it usually sends the '.call' too soon.
The method does work if you do it this way with this.connection on the server side Meteor method.
You need to make sure you send the method calls after you know that you are actually connected. This is what works at least with Meteor 0.8.2
I was using a file named ".next.js" to force meteor to use the newest unsupported javascript spec using a package.
Somehow this messed it up. Changed back to default javascript and it now works.
Thank you :)
init.coffee
Meteor.startup ->
# client init
if Meteor.isClient
Meteor.call "init"
methods.coffee
Meteor.methods
init: ->
console.log #connection.httpHeaders.host
it's that easy...
Or will it cause an error?
Example:
authClient = new FirebaseAuthClient(baseRef, function(error, user) { ... });
// Try to log in...
authClient.login('password', {email: 'some_email', password: 'some_password'});
// Before the callback from the previous line of code executes...
// Oh wait, I forgot to signup in the first place, let me do that:
authClient.createUser('some_email', 'some_password', function(error, user) { ... });
While it is safe to call those methods before the previous one has completed, in that you won't break corrupt data nor will exceptions be thrown, you might see some unexpected (and non-deterministic) behavior, depending upon the state of the user's account and session.
For example, if an existing session is detected (via looking at the browser cookie and localStorage), the FirebaseAuthClient will attempt to resume it which involves a quick verification step. Calling login before that step has completed will have different effects depending upon the user's account status.
Continuing that example, if the account exists and credentials are correct, you'll override the existing session and your callback will be invoked twice (once for the existing session, and once for the new one). If the account does not exist, or the credentials are incorrect, you may first receive one callback for the correct session, and then an error after receiving the bad credentials.
It might be helpful to hear a bit more about your specific use case and desired user experience so we may determine the clearest way to structure your code. Hope that helps!