I have a very similar issue than this one. I recently added has_secure_password to my User model. Everything is working great, except when I try to create a user from Facebook, which have a :friends attribute. In this case, i have this error when I try to #user.save!
> Validation failed: Friends is invalid
FB user creation was working perfectly before I added has_secure_password, and is still working when I save the users with #user.save(validate: false)
Once the user is already created and present in the database, the #user.save! method is working and the :friends are validated.
I also have a validates :password, length:{minimum:8}, on: :create in my User model, but the friends validation is still triggered even if I remove this line.
I could add a has_facebook? condition in my controller to completely skip any kind of validation when I try to create a user from FB, but I really want to understand why has_secure_password validation is triggered for something seemingly unrelated.
The validation message sounds strange.
But in documentation you see, that has_secure_validation adds a presence validation on password on create. So I think you somehow overwrite that validation message.
To say something more concrete I would need to see more of your code.
So documentation sais:
For further customizability, it is possible to supress the default validations by passing validations: false as an argument.
http://api.rubyonrails.org/classes/ActiveModel/SecurePassword/ClassMethods.html
I would assume, you set validations to false and care yourself about them. So you can require password only, when it's not a facebook registration.
Related
In SP2016 I'm making a call to the AddUserToGroup method of UserGroup.asmx. My function adds a user to a SharePoint permission group called "Supervisors".
If I supply a valid user account (in i:0#.w|domain\\username format), the call returns success, and almost always adds the user to the group. Sometimes, however, the user does not get added (although the call still returns success).
If I add a subsequent call to the GetGroupCollectionFromUser method, it returns a list of groups which include the target "Supervisors" group. But the user has not actually been added, and a refresh of the page will reflect that. How could that be?
The problem is not specific to a user, domain, or anything else that I can tell. The same user account may fail one time and succeed the next (returning success both times). The exact same problem occurs whether I use ASMX or REST (!!!). Verbose ULS logs have also not shed any light on the issue.
Has anyone seen this issue before?
I've extended the User model in my loopback application, and added phone number as a login method, I use the username field to do this, the only deal is that on login I get the 'email not verified' error, I have my own phoneNumberVerified field, and have overwritten the confirm method to validate the token against the emailVerificationToken and against the phoneNumberVerificationToken and update the corresponding flag, I thought of overwriting the original login method to not allow login only if both emailVerified and phoneNumberVerified fields are false (not just the email) but I don't know how to actually do the login the way loopback does it (I believe it creates an AccessToken or something), and I'm asking for some help on how to do this, thanks XD. I can do the overwriting and validations myself I just need to know how to do the actual login without using the original login method, since I'll be rewriting it.
So I figured out that I actually don't need email or phone number verified validation at all on login (later on the workflow will be required, but that'll be another use case, so it's irrelevant on login to me now XD). So when I was looking on how to overwrite the login method I realized that all the models code it's on the node_modules folder xD
node_modules/loopback/common/models/user.js
And found there in the login method a flag that validates if should check email verified or not, so on my startup script I just put this:
app.models.MyUser.settings.emailVerificationRequired = false;
That stops the email verified validation on login.
And maybe if some of you would like to override the login method I believe copying the whole method from the original user model up there and attaching it to your model and doing some modifications might work xD, it invokes the createAccessToken from the user model (itself) and that's what I believe creates the 'login', what I came to understand is that there is no "session" data, it creates an accesstoken when you successfully login, and as I've been doing just sending the token id to every request 'authenticates' your logged user.
Thanks for reading, have a nice day :)
I am attempting to track successful form Submissions using an event in Google Analytics via Google Tag Manager. My current setup successfully tracks when users submit the form. However, the event still fires even when the form submission is invalid and does not submit (ie a user hasn't filled out all of the required fields, clicks the submit button, the form attempts to validate, but comes back to the user with errors instead of submitting). I have the Check Validation feature on my listener checked which theoretically should keep the tag from firing if the form submission is prevented, so it's not the obvious error.
The form in question is created with Sitecore's Web Forms for Marketers. Colleagues of mine have had similar unsolved issues with their WFFM forms.
This particular form is used to gate content so that only users who fill out the form will have access to the content resource. So for example if I go to www.mydomain.com/resource I will be redirected to www.mydomain.com/form where if I fill out all of my information correctly and submit it I will then be redirected to the resource that I was originally attempting to view at www.mydomain.com/resource.
Here's my setup:
Tag 1
Name: Form Submission Listener
Type: Form Submit Listener
Wait For Tags: Checked
Max Wait Time: 2000 milliseconds
Check Validation: Checked
No advanced Settings
Firing Rule: On form pages by URL
Tag 2
Name: Event Form Submission
Type: Universal Analytics
Tracking ID: UA-.....
Enable Display Advertising Features: Checked
Track Type: Event
Category: Form
Action: Submission
Label: {{Form resource URL}}
Non-Interaction Hit: False
No More Settings
No Advanced Settings
Firing Rules: {{event}} equals gtm.formSubmit
Theoretically the Check Validation check box should prevent the tag from firing if the form does not successfully submit, but in the case of this form it does not. The tag fires regardless of whether the form submits or not.
Apologies that I cannot link to the form as it is for a client and behind security.
We were able to find an answer to our question via the Sitecore forums, but I wanted to pass it along for your benefit.
From Sitecore:
The Web Forms module provides the double level validation, 1-client validation, 2-server validation.
By default, the client validation is disable for the Required Field validator. So, when you press Submit, the form posts to the server, and returns with the validation error. It's a possible reason why Google Analytics considers that as a form submit.
Find the following item in the Master database:
/sitecore/system/Modules/Web Forms for Marketers/Settings/System/System Validation/NotEmpty
Find the "Enable Client Script" checkbox and enable it.
Save and publish the item.
Check whether the issue was fixed.
This fixed the issue for all of our text based fields. It did not fix the issue for the one checkbox on the form. I've followed up with sitecore on this, but I figured that I'd update here in the meantime.
With only the checkbox remaining I was also able to use a a macro and add to my original firing rule in google tag manager so that the event would not fire if the checkbox was not checked.
I created a Custom Javascript Macro called Radio Button Checked (not sure it's the best, but it worked), and added a new condition to my original Form Submission Rule: {{Radio Button Checked}} equals true
The macro:
function() {
var radioName = "radioButtonName";
try {
var buttons = document.getElementsByName(radioName);
for (var i = 0;i < buttons.length;i++){
if(buttons[i].checked) {
return true;
}
}
} catch(e) {}
return false;
}
EDIT: Sitecore got back to me about the checkbox issue.
From Sitecore:
Currently the CheckBox field type doesn't have the client-side validation. I registered it as a bug for the WFFM module. I'll let you know as soon as it's fixed.
They let me know also that this isn't something that will be fixed near-term so I need to continue using my GTM workaround for the check box field.
The Google Chrome plugin "Tag Assistant" is super helpful in debugging these sorts of issues. It will show you what (if any) structural or implementation issues exist on a given page that might be preventing your intended tracking behavior (https://chrome.google.com/webstore/detail/tag-assistant-by-google/kejbdjndbnbjgmefkgdddjlbokphdefk?hl=en)
My gut feel is that this issue is not specifically related to WFFM, but may be due to the implementation of the Tag Manager code on the page. I seem to recall having an issue like this when the Tag Manager include code gets dumped inside the auto-generated .NET tag when using WebForms in general. Google's docs (https://developers.google.com/tag-manager/quickstart) say to put it immediately after the opening tag, and I recall that being my issue with tracking form submits.
This is all from memory, so I could be wrong, but it's something else to check.
Good luck!
I'm absolutely new of Symfony, and I'm trying to implement a registration form that works only with invitation
but that can redirect two different forms for two different roles.
In practice if I send an invitation for an USER_TYPE1 role the client can only register like USER_TYPE1, if I send an invitation for an USER_TYPE2 the client can only register like USER_TYPE2 (and, of course, assigns the corrispondent role).
Is it possible?
thank you in advance for your help
UPDATE:
I want two different form because one user will be allowed to update file, but will also have to set his position and other important settings. The second user will only allow to download the files uploaded by the first kind of user, and his profile needs completely different information.
I do not have enough reputation to ask for details, but one thing that is not clear in your question is: why do you need 2 different forms? In your question, you mention 2 different roles, but why do you need 2 different forms? If you really need 2 different forms, then you should first:
- create a new form type
- create a new view (twig)
Like Boris suggested, I would keep some kind of token for every invitation sent, and associate an email address, and a role to it. Then modify your registration route so you can pass a token in there, like this:
register:
pattern: /signup/{token}
defaults: { _controller: MyBundle:Registration:signup }
In the registration action of your controller, you created the correct form type and display the appropriate twig, depending on the ROLE associated to the token you just got. And when handling a POST, you check the Token again to see if it matches the email address, and assign the proper ROLE when creating the User.
public function signupAction($token) {
// 1. Get the Token entity matching the $token variable
// 2. Create the correct form type
// 3. Display the correct twig for GET, assign correct ROLE to new User for POST
}
But you can't use FOSUserBundle as-is. You will have to overwrite the registration process. You can read the FOSUserBundle documentation about that.
What's certain is that, for every invitation you send, you should keep a token with a matching email address and ROLE (the role you want to give to that person).
I have a simple form without a entity that I use to send emails. Now I was testing in firefox and if I leave a field empty I will get a message. But now if I open the same form in Safari (that ignores required proprty) I won't get any message. The form->isValid() returs true even when I leave all fields blank...
How to validate this?
The in-browser validation is just a time saver to avoid a request to a server when a field is blank, but it's not a proper validation because it can be disabled on the browser level. You still should validate on the server side.
See this section — you need the NotBlank constraint.