I need to use Drupal 6's "hook_user" to update a 3rd party API whenever a user updates their profile.
Therefore I use the 'update' operation. The problem I am facing is that I just cannot see how I can stop execution if the 3rd party API update fails.
I.e. the user updates their username, but if the API fails, prevent Drupal from updating the local record.
function myhooks_user($op, &$edit, &$account, $category) {
switch ( $op )
{
case 'update':
if ( FALSE === updateAPI($data) )
{
drupal_set_message("Cannot update user information", "error", false);
return false;
}
break;
}
}
At the moment, the return false doesn't stop execution.
There is not a way to stop execution.
You should be able to overwrite $edit, with what's in the db. That way there wont be any change. I haven't tried this out, but it should work just fine.
Why do you want to do this anyways? You could just add a row in the db, and update the profile at a later time with cron instead, to avoid frustrated users that need to do the same edit over and over.
Related
I need to use WordPress Rest API to delete a user and all its own (maybe custom) posts.
I tried to call <url_base>/wp/v2/users/<id> and I have to provide a further parameter ?reassign=USER_ID to reassign its posts to another user.
A silly solution should be adding a "garbage" user to the system and assign him all deleted posts. Then I can create a job to delete all posts. It seems a very stupid way to me.. :(
I just want to delete them. I can do it from WP admin panel... why I can't via Rest Api?
Thanks
EDIT
Passing "reassign" as an empty params (null is not accepted...) the API informs me that I'm not able to delete my own profile. I'm testing it as a subscriber (end user), but I need to be able to manage and delete my own data... Am I wrong?!
This is my solution... maybe not the best one, but it seems to work.
I added delete_users and remove_users capabilities to the Subscriber role (for my convenience).
My /DeleteUsers rest endpoint check for the user ID encrypted inside the JWT token that is sent in header and compare it with the user_id params. If they match, I can delete the user.
Now I just have to avoid that a user can access the WP Admin panel and make some mess!
This is the code:
function myDeleteProfile($data) {
require_once(ABSPATH.'wp-admin/includes/user.php');
$headers = getallheaders();
if(!isset($headers['Authorization']) || !$headers['Authorization']) {
return array('esito'=>'ko', 'descrizione'=>'Fail message!');
}
$jwt_parts = preg_split('/\./', $headers['Authorization']);
$jwt_decoded = json_decode(base64_decode($jwt_parts[1]));
$jwt_user = $jwt_decoded->data->user->id;
if( intval($data['user_id']) != intval($jwt_user) ) {
return array('esito'=>'ko', 'descrizione'=>'User cannot delete.');
}
else {
if( wp_delete_user($jwt_user,null) ){
return array('esito'=>'ok', 'descrizione'=>'Deleting...');
}
else {
return array('esito'=>'ko', 'descrizione'=>'Error.');
}
}
}
I use Google recaptcha to auth user is not robot, this part works! :)
I use
Accounts.validateLoginAttempt((data) => {
if (someThingThatWillValidateTrueIfUserIsLoggedIn) {
return true // Will not run google Captcha security messure..
}
}
to make my post request to google inorder to verify the public. I guess my question is what should I use to return true imediatly from validateLoginAttempt. If I remove validateLoginAttempt the user will stay logged in after refresh.
I tried using
Accounts.user() // Undef
Meteor.user() // Undef
this.connection // Undef
this.userId // Undef
But with no luck... How do i use validateLoginAttempt and keep the ability of users staying logged in after browser refresh?
Well, this took a while to figure out :( , the fact is that the one Accounts parameter contains the resume data as well so doing
Accounts.validateLoginAttempt((data) => {
if (data.type === 'resume' && data.allowed) {
return true;
}
... code for doing captcha check..
}
Works well!! :)
i am trying to save form state in database and want to view in a listing page with its error validation.
i.e, i want to validate a previously saved form state from my database.
this is a node type form .
i had already tried node_validate its not working because i fetch the data before submitting the node . so there is no nid and for that it is not working
and also tried drupal_validate_form but it is showing
[form_token] => The form has become outdated. Copy any unsaved work in the form below and then reload this page
EDIT
Any one with any help , "How to save a form inputs in data base and retrive it from database with out form submision.
Thank You In advance
Any help is most Appreciable.
If you look in Drupal Core, you see this in includes/form.inc at the drupal_validate_form function:
if (isset($form['#token'])) {
if (!drupal_valid_token($form_state['values']['form_token'], $form['#token'])) {
$path = current_path();
$query = drupal_get_query_parameters();
$url = url($path, array('query' => $query));
// Setting this error will cause the form to fail validation.
form_set_error('form_token', t('The form has become outdated. Copy any unsaved work in the form below and then reload this page.', array('#link' => $url)));
// Stop here and don't run any further validation handlers, because they
// could invoke non-safe operations which opens the door for CSRF
// vulnerabilities.
$validated_forms[$form_id] = TRUE;
return;
}
}`
This shows that the "form has become outdated" message is being set here. So, you can make the isset($form[#token']) condition false by unsetting #token to prevent this message from appearing.
All you have to do is load the form state you're going to validate, and call
unset($form[#token']); before you call drupal_validate_form.
I am seeing a repeatable issue where a user authenticates ("logs in") with a Meteor server, and then a client subscription that depends on userId is updated (and dependent UI templates reactively update) before Meteor.userId() registers the successful login.
For example, in this code snippet, the assert will throw:
var coll = new Meteor.Collection("test");
if (Meteor.isServer) {
Meteor.publish('mineOrPublic', function () {
// Publish public records and those owned by subscribing user
return coll.find({owner: { $in: [ this.userId, null ]}});
});
}
if (Meteor.isClient) {
var sub = Meteor.subscribe('mineOrPublic');
var cursor = coll.find({});
cursor.observe({
added: function (doc) {
if (doc.owner) {
// This should always be true?!
assert(doc.owner === Meteor.userId());
}
}
});
}
Analogous to the added function above, if I write a template helper that checks Meteor.userId(), it will see a value of null, even when it is invoked with a data context of a document with an owner.
There is apparently a race condition between Meteor collection Pub/Sub and the Account userId update mechanisms. It seems to me that Meteor.userId() should always be updated before any subscriptions update based on a change in this.userId in a server publish function, but for some reason the opposite usually seems to be true (that is, the assert in the code above will usually throw).
The reason I care is because I have packages that depend on obtaining a valid Meteor Authentication token (using Accounts._storedLoginToken()) on the client for use in securing HTTP requests for files stored on the Meteor server. And the authentication token isn't correct until Meteor.userId() is. So the flow of events usually goes something like this:
User logs in
Publish function on server reruns based on the change in this.userId.
Client begins receiving new documents corresponding to the change in userId.
UI Template reactively updates to add DOM elements driven by new documents
Some of the DOM elements are <img> tags with src= values that depend on the data context.
HTTP requests are triggered and ultimately fail with 403 (forbidden) errors because the required authentication cookie hasn't been set yet.
Meteor.userId() finally updates on the client, and code reactively runs to set the authentication cookie
Helpers in the template that depend on a session variable set in the cookie update code are rerun, but the DOM doesn't change, because the URLs in the <img> tags don't change.
Because the DOM doesn't change, the tags don't retry their failed attempts to load the images.
Everything settles down, and the user has to manually reload the page to get their images to appear.
I've come up with two possible approaches to work around this issue:
In the template helper that generates the URL for the <img> tag, always append a dummy query string such as: "?time=" + new Date().getTime(). This causes the DOM to change every time the helper is called and fixes the problem, but it screws-up browser caching and if not coordinated will cause some assets to unnecessarily load multiple times, etc.
In every template helper that touches document data add a test of:
if (this.owner && this.owner !== Meteor.userId()) {
// Perhaps Meteor.loggingIn() could be used above?
// Invalid state, output placeholder
} else {
// Valid state, output proper value for template
}
I really hope someone knows of a less kludgy way to work around this. Alternatively, if consensus arises that this is a bug and Meteor's behavior is incorrect in this respect. I will happily file an issue on Github. I mostly really enjoy working with Meteor, but this is the kind of gritty annoyance that grinds in the gears of "it just works".
Thanks for any and all insights.
After trying lots of things, this variation on the example code in the OP seems to consistently solve the race condition, and I find this an acceptable resolution, unlike my initial attempted workarounds.
I still feel that this kind of logic should be unnecessary and welcome other approaches or opinions on whether Meteor's behavior in the OP sample code is correct or erroneous. If consensus emerges in the comments that Meteor's behavior is wrong, I will create an issue on Github for this.
Thanks for any additional feedback or alternative solutions.
var coll = new Meteor.Collection("test");
if (Meteor.isServer) {
Meteor.publish('mineOrPublic', function (clientUserId) {
if (this.userId === clientUserId) {
// Publish public records and those owned by subscribing user
return coll.find({owner: { $in: [ this.userId, null ]}});
} else {
// Don't return user owned docs unless client sub matches
return coll.find({owner: null});
}
});
}
if (Meteor.isClient) {
Deps.autorun(function () {
// Resubscribe anytime userId changes
var sub = Meteor.subscribe('mineOrPublic', Meteor.userId());
});
var cursor = coll.find({});
cursor.observe({
added: function (doc) {
if (doc.owner) {
// This should always be true?!
assert(doc.owner === Meteor.userId());
}
}
});
}
This code works by giving the server publish function the information it needs to recognize when it is running ahead of the client's own login state, thereby breaking the race condition.
I think this is something that Meteor should do automatically: clients should not see documents based on changes to this.userId in a publish function until after the client Meteor.userId() has been updated.
Do others agree?
I tried with this code that works on server too. In association with FileCollection package.
if (Meteor.isServer) {
CurrentUserId = null;
Meteor.publish(null, function() {
CurrentUserId = this.userId;
});
}
....
OrgFiles.allow({
read: function (userId, file) {
if (CurrentUserId !== file.metadata.owner) {
return false;
} else {
return true;
}
}
...
I'm using the Accounts API to manage users. My app first tries to log in a user using their credentials, and in case that results in an error, it creates a new user account using the input credentials.
// Log the user in
Meteor.loginWithPassword(username, token, function(error) {
if(error) { // create a new user account, log them in and show the page
Accounts.createUser({
username: username,
email: username + '#example.com',
password: token,
profile: {name: username}
}, showThePage);
}
else { // show the page
//showThePage();
window.location.reload();
}
});
But this code block executes only when the user was previously logged out from their browser, and if that is the case it takes 2-3 seconds for Meteor to log the user in using loginWithPassword. As I'm using v0.5.0, there is no Meteor.loggingIn(), and the only thing I have is Meteor.userLoaded(). Meteor, for some reason, performs the login operation twice -- once by loading a placeholder user (that has only its userId property set) and again by loading the actual user. This makes userLoaded() return true twice, because of which my loader image doesn't work as expected.
Also notice that in the else block inside loginWithPassword, I'm doing a window reload. I've a function showThePage() which contains all the template data & event binding code. That function retrieves data using the username of the logged in user. Now because when that function in else block executes there isn't a real user logged in (remember meteor takes time to log the user in), no data gets fetched.
Is there a workaround for this problem?
First of all Meteor.userLoaded goes away after you upgrade beyond 0.5.0. You should check if Meteor.userId() === null to know if the user login has completed, which works in 0.5.0 and beyond. It may get called multiple times, as you have noted, but only when it has a real value has the login completed.
If you really can't update to 0.5.1, use a session variable to store loggingIn in between the call to loginWithPassword and the callback.
Session.set('loggingIn',true);
Meteor.loginWithPassword(...
Session.set('loggingIn',false);
});
Then, use the Session.get('loggingIn') call where appropriate.
Want to adapt userLoaded() instead?
var userLoadedTimes = 0; // can't use session variable because it would mess up reactive context on increments
Session.set('loggingIn',false);
Meteor.autorun(function () {
var userLoaded = Meteor.userLoaded(); // reactive.
if (userLoaded)
userLoadedTimes++;
if ((userLoadedTimes % 2 == 0) && (userLoadedTimes != 0))
Session.set('loggingIn',true);
else
Session.set('loggingIn',false);
});
What's that modulo doing there? Well if userLoaded has called a reactive context twice for some reason, you have actually logged in. So we check if userLoadedTimes is a multiple of two/even. All other times, i.e., when userLoadedTimes is odd (userLoadedTimes % 2 == 1), we're looking at the fake user... which means we're still loading the real user!
If this doesn't work, apply the even/odd logic to the first solution using session variable changes on the callback, in the event Meteor calls the loginWithPassword callback twice.