loopback auth treats User.email case sensitive

[Morriz]

And it goes the same for User.username, but that depends on taste...

My use case: I can't login when my iOS automatically sets the first character to uppercase...but please look beyond this ;)

[esco]

It looks like the findOne query that searches by username or email isn't case sensitive https://github.com/strongloop/loopback/blob/1cabd74308e8c57aa8033641c77bccfcf86e57f3/common/models/user.js#L196-L203

@raymondfeng is it possible to do a case-insensitive query?

[slonoed]

@Morriz, maybe good way to set autocapitalize="off" to your input.

[Morriz]

Sure, that would be handy as well, but is not a solution to the (bigger) problem :)

On 06 Apr 2015, at 21:16, Dmitry Manannikov [email protected] wrote:

@Morriz, maybe good way to set autocapitalize="off" to your input.

—
Reply to this email directly or view it on GitHub.

[slonoed]

@Morriz, what problem?

In rfc2821

The local-part of a mailbox MUST BE treated as case sensitive.

If you need case insensitive emails, you can use beforeRemote hook to change it on login and sign up.

[esco]

@SLonoed @Morriz

That quote is not referring to email addresses.

Case-insensitive emails make a lot of sense. Imagine if gmail addresses were case-sensitive, there would be so much confusion. Github also does case-insensitive email login.

[Morriz]

Like I said it in the title: emails were not treated case insensitive when I said that. It does now?

On 06 Apr 2015, at 21:53, Esco Obong [email protected] wrote:

@SLonoed @Morriz

That quote is not referring to email addresses.

Case-insensitive emails make a lot of sense. Imagine if gmail addresses were case-sensitive, there would be so much confusion. Github also does case-insensitive email login.

—
Reply to this email directly or view it on GitHub.

[Morriz]

Ha, I always thought emails were treated case insensitive. Learned something new today ;)

On 06 Apr 2015, at 21:34, Dmitry Manannikov [email protected] wrote:

@Morriz, what problem?

In rfc2821

The local-part of a mailbox MUST BE treated as case sensitive.
If you need case insensitive emails, you can use beforeRemote hook to change it on login and sign up.

—
Reply to this email directly or view it on GitHub.

[slonoed]

@esco, I agree with you. Almost all mail services use case insensitive. But include it to loopback by default – bad idea. Loopback provide ability (with few lines of code) to make email insensitive. This is enough.

[esco]

@SLonoed fair enough that its flexible, but my vote is for the most common use case to be the default with the ability to make it case-sensitive. :+1:

[Morriz]

I agree, it's value (i.e. supporting majority of well known use cases) I am after mostly, and I bet most ppl are...

On 06 Apr 2015, at 22:35, Esco Obong [email protected] wrote:

@SLonoed fair enough that its flexible, but my vote is for the most common use case to be the default with the ability to make it case-sensitive.

—
Reply to this email directly or view it on GitHub.

[slonoed]

Supporting majority well known use cases must be in new versions of specs. And after supporting in code. When software developers build soft based on use cases instead of specs, they build new internet explorer. Nah..

[esco]

@SLonoed sometimes being pragmatic is good. This would cover 99% of use cases. Case-sensitive email lookups aren't very useful.

[technicallyfeasible]

+1

I agree to supporting the most common usecase. No service I know of treats emails as case sensitive and if they do it leads to a lot of confusion with seemingly not being able to login.
I got infuriated by such behavior myself on several occasions.

[slonoed]

@technicallyfeasible why you got infuriated? You read email specs?

[technicallyfeasible]

@slonoed Yes, I know the specs, I have implemented an email parser myself once but have you tried to explain that to a potential user? They usually just move on to the service that is more accommodating.

[OwenBrotherwood]

https://github.com/strongloop/loopback/issues/1354 shows a possible way to hijack the access to a model and make the key case insensitive by allways saving the key as lower case and allways accessing as lower case.

Is this a way out for the iOS users and lower case emails ...

The method is totally contained in the API so no need for changing input from the user on the user "GUI"

The 1354 issue reminded me of this issue.
@raymondfeng as someone else has allready "at" Raymond.

Edit:
Something like this as a boot script (Note: the syntax and correctness are not checked: written "freehand"

Edit Edit: Maybe it does not work as a boot script: but I hate the concept of altering Users.js

'use strict';
module.exports = function lowercaseEmails(app){
  var Users = app.models.Users; 

  Users.observe('access', function filterEmailQueryField(ctx, next){
    if ( ctx.query.where !== undefined && ctx.query.where.email !== undefined ) {
      ctx.query.where.email = ctx.query.where.email.toLowerCase();
    }
    next();
  });

  Users.observe('before save', function filterEmailDataField(ctx, next){
    if (ctx.instance !== undefined && ctx.instance.email !== undefined){
            ctx.instance.email = ctx.instance.email.toLowerCase();
    }else if (ctx.data.email !== undefined){
                ctx.data.email = ctx.data.email.toLowerCase();
    }
    next();
  });
};

[jlvdh]

@OwenBrotherwood your code is working fine for me in user.js. I only had to change app.models.Users to app.models.User.

[esco]

@OwenBrotherwood this solution breaks if you have a scope defined on the User model. The scope will create an and query which doesn't get detected by the if

if (ctx.query.where && ctx.query.where.email) {
  ctx.query.where.email = ctx.query.where.email.toLowerCase();
} else if (ctx.query.where && ctx.query.where.and) {
  ctx.query.where.and = ctx.query.where.and.map(function(condition){
    Object.keys(condition).forEach(function(key){
      if (key === 'email') {
        condition[key] = condition[key].toLowerCase();
      }
    });
    return condition;
  });
}

[OwenBrotherwood]

@superkhau Can something be done with this issue: currently triac and no assignee. @esco gave some input that should be understand. Currently, I have had to do a context switch from javascript to IBM Mainframe work which is hopefully finished soon. "I'll be back"

[superkhau]

@OwenBrotherwood I can bump this up to major.

@raymondfeng ^

[OwenBrotherwood]

@superkhau The issue seems to interest a lot of people, so it would be good to have a standpoint on it.
It is possible to support the normal use of email case sensitivity, as default or option, without going against the stated rfc's, in the framework

[superkhau]

Duplicate of #1723.

@OwenBrotherwood I will bring this up during sprint planning. Otherwise, we accept PR's so feel free to submit a patch. ;)

[OwenBrotherwood]

@superkhau PR: will do if I get there before sprint

[bajtos]

I am proposing to add a new setting to the User model that would allow LoopBack apps to decide whether they want case-sensitive checks of emails or not.

[OwenBrotherwood]

@bajtos sounds good.
This issue is in what way the user email is used in Authentication, ie strict case sensitive or not and that the framework is used to reduce load on the application

https://github.com/strongloop/loopback/issues/1723 is the other issue of interest, that seems to have a life of it's own but is "interesting" as to what is a valid user email, that is in turn used in Authentication

[ritch]

+1 for User.settings.caseInsensitveEmail ...we should probably default it to true in 3.0 IMO.

[superkhau]

+1 for true in LB3

[OwenBrotherwood]

:+1: Great work.