I've read in the drupal documentation that hook_user should be invoked for the login operation. To test this I've added a call to drupal_set_message at the top of my modules hook implementation and the only message I'm receiving is a call with 'load' as the $op.
I've confirmed that drupal_set_message can be called multiple times and it doesn't erase the previous message, so I'm confident that hook_user is only being invoked the one time.
Any good reasons for why hook_user isn't being invoked with 'login' as an operation when I'm logging in?
Drupal version is 6 and my module is called "favequest_favorites" its implementation of hook_user (for testing purposes) is:
function favequest_favorites_user($op, &$edit, &$user, $caterogy=NULL) {
drupal_set_message($op);
}
As is often the case I've tracked this down to the interaction of modules.
Do not use the "Login Destination" module if you plan on using hook_user in your modules.
It bails out before all other modules may have had a chance to execute.
You've got a typo with the spelling of the "$caterogy" variable, but that shouldn't matter, since you're not using it in this test:
function favequest_favorites_user($op, &$edit, &$user, $caterogy=NULL) {
Using your code, I get four messages on login:
load
load
login
load
How about if you edit the user account? Do you get the "view" $op on the My Account page, and the "form" $op when you edit it?
Interesting that I don't get the "logout" $op when I log out--I assume that has something to do with a redirect, once I'm no longer authenticated.
See if you have a drupal_goto after you login.
http://drupal.org/node/228688
About drupal_set_message - The messages are saved into the session. When you login the session gets reset, and that might be the reason you don't see them. For a quick debug I recommend using devel module with dd function or system log messages.
Adi
Related
I am building a Meteor application with some custom authentication in addition to the built-in accounts MDG package.
I want to have a function I call at the front of Meteor methods to verify authentication. If authentication fails, I would like to do the equivalent of PHP's die() function - return a message and stop execution.
I could always do something like this: if(!checkAuth()) return "Not Authenticated", however it would be nice if I could just do checkAuth() and that function takes care of stopping execution if correct permissions are not met.
Is there a way to do this?
The easy way is to throw a new Meteor.Error. If not caught it will stop the currently running function, and if it is thrown from a method or a subscription it will appear on the client-side.
function checkAuth(user) {
if(!isAuthenticated(user)) {
throw new Meteor.Error('not-authenticated', 'Users need to be authenticated to do foo')
}
}
The above thrown error server-side will appear on the client with the reason and the details. It allows you to do custom error handling tailored to whatever is happening. If any other kind of error is thrown, it will appear as "500 Internal server error".
Note that this mechanism is similar to check. You could even use a custom Match pattern :
check(user, MyPatterns.authenticatedUser)
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.
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...
The method WorkflowInstanceProxy.EndResumeBookmark returns an enum BookmarkResumptionResult. When will this return NotReady? What I really want to know is how I can create a scenario so that this occurs, so that I can write tests to verify that my implementation of an extension is correct.
MSDN says(http://msdn.microsoft.com/en-us/library/system.activities.bookmarkresumptionresult.aspx):
NotReady: The bookmark resumption was not scheduled because the runtime has not yet created the bookmark. The host should wait until another idle point to try resumption again.
I saw it when you want to resume the bookmark and the workflow is not unloaded yet.
I hope this helps.
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!