deploying an internal (corporate) API manager 2.0.0 we found a limitation - the email address validation apparently enforces email validation with 2-4 email :
/store/site/themes/wso2/templates/ui/validation/custom-validation.js:
$.validator.addMethod('validEmail', function(value, element) {
var emailRegex = /^([A-Za-z0-9_\-\.])+\#([A-Za-z0-9_\-\.])+\.([A-Za-z]{2,4})$/;
return emailRegex.test(value);
}, i18n.t('Invalid email address'));
However - email addresses today may have even long last domain name (e.g. someuser#stad.gent, otheruse#my.internal.corporation)
I see the validation logic is implemented in the followinf file:
repository/deployment/server/jaggeryapps/store/site/themes/wso2/templates/ui/validation/custom-validation.js
Question: is the file the only place where the email format is enforced? (Users are managed in AD, so the default user view / management UI doesn't concern us too much atm)
Seems the only place where the email is validated is the script:
repository/deployment/server/jaggeryapps/store/site/themes/wso2/templates/ui/validation/custom-validation.js
Related
I am attempting to create Reset Password functionality using Djoser. I am successfully hitting my API's auth/users/reset_password/ endpoint, which is then sending an email as expected. But the problem is occurring in the content of the email. It is sending a redirection link to my api, rather than to my frontend.
Please note, any <> is simply hiding a variable and is not actually displayed like that
Here is an example of what the email looks like:
You're receiving this email because you requested a password reset for your user account at <api>.
Please go to the following page and choose a new password: <api>/reset-password/confirm/<uid>/<token>
Your username, in case you've forgotten: <username>
Thanks for using our site!
The <api> team
The goal with this email is to send the user to the /reset-password/confirm/ url on my frontend, not on my api, which is currently occurring.
Here are my DJOSER settings:
DJOSER = {
'DOMAIN': '<frontend>',
'SITE_NAME': '<site-name>',
'PASSWORD_RESET_CONFIRM_URL': 'reset-password/confirm/{uid}/{token}',
}
The expected behavior is for the DOMAIN setting to alter the link that is being placed in the email, but it is not. I can't seem to find reference to this particular problem within the docs.
Any help here would be greatly appreciated, thanks.
I figured it out:
Due to Djoser extending the package django-templated-mail, the variables DOMAIN and SITE_NAME have to override django-templated-mail setting rather than Djoser's setting. So, you have to pull variables specific to django-templated-mail out of the Djoser variable.
The working setup actually looks like:
DOMAIN = '<frontend>',
SITE_NAME = '<site-name>',
DJOSER = {
'PASSWORD_RESET_CONFIRM_URL': 'reset-password/confirm/{uid}/{token}',
}
Setup
I am using AWS Cognito to manage the user registration and user access for my web application. Specifically I am using the Cognito hosted UI. This means that Cognito presents a UI for my users to register, I do not have access to modify the user sign-up or login pages for my application (other than the controls provided by Cognito). I am using email addresses as usernames, so new users are simply asked to provide an email address and password.
Problem
Cognito treats email addresses as case sensitive. If a user signs up with the email address JOHN_smith#randommail.com, they cannot then sign in using john_smith#randommail.com.
I want user email addresses for sign-up and login to be case insensitive.
What I have tried
Usually this would be trivial to deal with by setting the email address to the lowercase in the client before sending it to the server. However I do not have access to the client UI as it is hosted by Cognito.
My plan therefore was to try using a Lambda function invoked by a Cognito pre-signup trigger to lowercase the email supplied by the user.
Pre sign-up
Amazon Cognito invokes this trigger when a user attempts
to register (sign up), allowing you to perform custom validation to
accept or deny the registration request.
Here is the lamdba function I wrote:
'use strict';
console.log('Loading function');
exports.handler = (event, context, callback) => {
console.log('Received event:', JSON.stringify(event, null, 2));
var triggerSource = event.triggerSource;
console.log('Received triggerSource:', triggerSource);
var email = event.request.userAttributes.email;
console.log('Received email:', email);
var modifiedEvent = event;
if (email !== null) {
var lowerEmail = email.toLowerCase();
modifiedEvent.request.userAttributes.email = lowerEmail;
console.log('Set email in request to', lowerEmail);
console.log('Modified event:', JSON.stringify(modifiedEvent, null, 2));
} else {
console.log('Email evaluated as NULL, exiting with no action');
}
// Return result to Cognito
callback(null, modifiedEvent);
};
This 'worked' in the sense that the email address in the event request was modified to be lowercase (john_smith#randommail.com). However, it seems the account has already been created in the userpool by the time my Lambda function receives this event. Changing the email address in the request had no effect - the original email address (JOHN_smith#randommail.com) still appears in my user pool. I suspect the only fields in the event that have any effect are the response fields. Here is what my modified event looks like:
{
"version": "1",
"region": "us-east-1",
"userPoolId": "us-east-1_xxxxxxx",
"userName": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxx",
"callerContext": {
"awsSdkVersion": "aws-sdk-java-console",
"clientId": "xxxxxxxxxxxxxxxxxxxxxx"
},
"triggerSource": "PreSignUp_SignUp",
"request": {
"userAttributes": {
"email": "john_smith#randommail.com"
},
"validationData": null
},
"response": {
"autoConfirmUser": false,
"autoVerifyEmail": false,
"autoVerifyPhone": false
}
}
My question
I'm looking for ideas or examples to make my user registration and login case insensitive. This might include changes to my lambda trigger approach or something else entirely.
Please note I know I could implement my own UI, which I will only do as a last resort.
Fixed on new user pools. You can turn off case sensitivity now.
https://aws.amazon.com/about-aws/whats-new/2020/02/amazon-cognito-user-pools-service-now-supports-case-insensitivity-for-user-aliases/
You could trigger a Lambda function after sign-up to change the email to lowercase. Without actually testing it, you should be able to trigger a Lambda post confirmation. That Lambda could use AdminUpdateUserAttributes API, called from your SDK of choice, to change the email to lowercase.
Note that user names are also case sensitive.
Since username is case sensetive: why not just use the username as the email address and have the prehook populate the email field with the username?
Make username lowercase when creating the account. Make username lowercase when logging in. At least this way you only have to re-create users that have uppercase characters. Or you can rebuild your entire user pool and migrate the users, but who knows what affect that will have on passwords and MFA. It doesn't seem worth the trouble with an existing user pool. Hopefully you are doing a brand new project and you can select the case insensitive option when creating the user pool.
After multiple attempts, I have tried adding a small css for username field on login page and forgot password page.
#amplify-id-8,#amplify-id-0{
text-transform: lowercase;
}
#amplify-id-0::placeholder,#amplify-id-8::placeholder{
text-transform: capitalize;
}
This worked for me on the amplify-authenticator , I used as a login component.
another possibility is if you can create a user signup api, which would create the user in the cognito. after trimming email along with performing lower case on email. you can perform your custom steps before that.
you are right that pre-signup trigger basically get invoked after signup is performed.
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-sign-up.html#aws-lambda-triggers-pre-registration-tutorials
I have cognito set up with a pre sign up lambda which returns event with following set:
event.response.autoConfirmUser = true;
event.response.autoVerifyEmail = true;
this correctly marks user email and user itself as confirmed in aws console. But while trying to login I get the error "User does not exist." from cognito aws api, any ideas?
Cognito Pool is set up to use "email address" as "username" and this makes following even weirder - I can create new user with the same email address as above and authenticate fine. But what I ending up with are two confirmed users with the same email address!
My use case is relatively simple - I invite users to join via email so the email is confirmed already in a sense, that's why am using pre sign up lambda to mark user and email as confirmed/verified.
Any help greatly appreciated!
Thanks,
Tomek
I'm building REST API.
I have following structure
GET /user/{id} - get
POST /users - Create user
PUT /users/{id} - Update user
DELETE /users/{id} - Delete user
The problem is following. As I got from many tutorials/articles - it is bad practice to use action in URL. But what to do with such actions like:
check email (is unique)
recover user by email
?
Assume user registration. User submits form ( POST /users ) and I need to check if email is unique. Do I need to do it in same api method and return validation errors as response body?
Or do I need to create something like
POST /users/email
And what about user recovering by email? Where do I need to do it? Because recover is verb
POST /users/recover
I'm not sure, that I'm doing it right and I can't find correct explanation for that situation.
Validating the e-mail and registering the user
If you want, you can have an endpoint to check whether an e-mail is already registered or not. It's up to your requirements. So, you can have something as following and then send the e-mail which will be validated in the request payload:
POST /users/email/validation
{
"email": "mail#example.com"
}
The endpoint above can be invoke, for example, when the user completes the e-mail field of your account registration form.
However, do not forget checking if the e-mail is already registered when creating a user:
POST /users
{
"firstName": "John",
"lastName": "Doe",
"email": "mail#example.com",
"password": "123456"
}
If an e-mail is already registered, you could consider returning a 409 Conflict status code and a payload that includes enough information for a user to recognize the source of the conflict.
Recovering the password
I'm unsure if this is your requirement, because of this I posted a comment asking for clarification. I presume you are trying to recover the password of a user, assuming the user has no more access to their account.
If so, you could have an endpoint as following and then send the e-mail of the user in the request payload:
POST /users/password/recovery
{
"email": "mail#example.com"
}
Then your server can send a link with a token to the e-mail specified in the payload. Only send the e-mail if the e-mail specified in the payload is registered in your application, of course.
The link should take the user to a page where they will enter the new password and, when submitting, an endpoint to replace the password of the user will be invoked, sending the token and the new password to the server:
PUT /users/password?token=SomeValueGoesHere
{
"password": "654321"
}
I want to know is there any way to get user subscrition / unsubscrition to email campaign ?
Is it saved in one of databases/tables in MSSQL ?
If you use the approach with opting in and out being determined on the fact if user is in role, then it is stored in the aspnet_UsersInRoles table in your core database. This table does not keep the information when role was assigned to the user. That's why you cannot get information when user subscribed or unsubscribed to email campaign.
The only thing you can check is if user is in the role:
user.IsInRole(roleName)
The user's subscription is driven by the users role, but It is possible to get the users subscriptions in ECM, You just have to use the api.
You can get the contact from the email address:
string fullName = commonDomain + "\\" + Util.AddressToUserName(username);
var contact = Contact.FromName(fullName);
var subscriptions = contact.GetSubscriptions();
Once you have a contact you can call the GetSubscriptions() method which will return the recipient lists the user is signed up to. There are a host of other methods you can call on a contact and if there is a a way to get the date unsubscribed/subscribed it will be here.
If not reflect Sitecore.EmailCampaign.dll and keep looking! There might be some extra information in the automation states table in the Analytics database. More info on automation state here:
https://www.sitecore.net/learn/blogs/technical-blogs/sitecore-magnified/posts/2013/09/ecm-automation-states-magic.aspx
Also noticed there is a method GetUnsubscribersStatistics on the Sitecore.Modules.EmailCampaign.Core.Analytics.AnalyticsHelper class. This will have the date of unsubscription.