It should fail.
It's not a concern: you login as usual, without any relation to the org. Anyway, it might look strange.
Opening this one up for discussion. How do you think this should work?
My first idea would be to use some kind of error message, asking the user to go to the general login, which I think is the more explicit solution. A quick & dirty sketch:

A concern, is that it may expose that the username is not a member of the organization. This could be avoided with a more generic "Username/password invalid. Not a member of team? Go to the general login." for all failed logins.
More ideas:
Another extra thing we can consider is to disable the login page for user subdomains (javitonino.carto.com/login) and automatically redirect to the central login (carto.com/login). This makes it easier to avoid problems logging in between multiple clouds (if you to the login page of an user/org in a different cloud, your login doesn't work).
cc @saleiva
Hey, I actually love your latest idea about disabling login from user subdomains.
On the other hand, we would still need a solution for when an user try to login within an organization while doesn't belonging to it. For that particular scenario, I propose we do your second idea, we raise an error saying "Not a member of {organization_name}?, Go to carto.com/login"
Let me know if you need a quick mockup for that.
Yes, a mockup would be great. Specially since the organization login page can be customized and it's a bit harder to do something that looks nice in different customizations.
Thanks!
Another question: What should we do for on-premise / open source? I suggest keeping current behaviour in that case, as there is not a clear place to send the user to (no Central, so all login URLs are for an organization/user).
Sounds good to me
Hi guys, I prepared some mockups and my proposal is:



@carlostallon Looks good to me! Just one detail, I would not put the domain ("@nyu.edu" in your example) in the copy because it can actually be a long list of allowed domains. Also, it might disclose some potentially sensitive data (some private email domain).
So I'd just say something generic like in the signup page: "Please, remember to use an email address belonging to this organization to login to your account.". Sounds good to you?
@javitonino you are right! updated!

Cool! Moving to Done in design then!
Could someone add some instructions for acceptance? Thanks!
They are in the PR :)
Let's stop this PR for a minute. I've been testing, and it breaks auto-user creation via SAML (and I'm pretty sure that via LDAP as well). Moving back to development and stopping to think about it.
For the record, knowing the proper login (or even signup) page for university org users has been a big source of confusion.
@ohasselblad Not sure what the problem is for login, since you can login from pretty much anywhere. Can you elaborate? I know about signup (which is a bit more complicated, since you can signup inside or outside the org), we have that ticket in the backburner. But it seems to me that login should not be a problem, carto.com/login works for everyone.
Sorry, you're right. Yeah, the signup was the only source of confusion.
The issue I mentioned is not an issue for now, as it only affects the SaaS. I'll document what needs to be done in https://github.com/CartoDB/cartodb/issues/11108
This can continue as it is for now, but we need to double check that Google signup into an org from the login page still works.
Most helpful comment
Sorry, you're right. Yeah, the signup was the only source of confusion.