Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Username should be unique #46

Closed
leocwolter opened this issue Aug 21, 2014 · 11 comments
Closed

Username should be unique #46

leocwolter opened this issue Aug 21, 2014 · 11 comments

Comments

@leocwolter
Copy link
Contributor

From now, the field username of the model User should be unique and not case sensitive.
If there's a user called 'leonardo.wolter', no one can create a user called 'Leonardo.wolter'

@csokol
Copy link
Contributor

csokol commented Aug 21, 2014

Why?

Chico Sokol

On Thu, Aug 21, 2014 at 12:52 PM, Leonardo Cesar Wolter <
notifications@github.com> wrote:

From now, the field username of the model User should be unique and not
case sensitive.
If there's a user called 'leonardo.wolter', no one can create a user
called 'Leonardo.wolter'


Reply to this email directly or view it on GitHub
#46.

@leocwolter
Copy link
Contributor Author

We are having issues at guj.com where a troll is creating multiple fake users with the username of other users http://www.guj.com.br/26754-ignorem-e-apenas-um-troll

@csokol
Copy link
Contributor

csokol commented Aug 21, 2014

:-(

Right, we will have to do some manual work to fix this when we deploy our
new version.

Chico Sokol

On Thu, Aug 21, 2014 at 1:18 PM, Leonardo Cesar Wolter <
notifications@github.com> wrote:

We are having issues at guj.com where a troll is creating multiple fake
users with the username of other users
http://www.guj.com.br/26754-ignorem-e-apenas-um-troll


Reply to this email directly or view it on GitHub
#46 (comment).

@leocwolter
Copy link
Contributor Author

I guess we can just validate the new users from now

@defaultbr
Copy link

Yes, validate new users will be enough (case insensitive)

@monitorjbl
Copy link
Contributor

Looks like this commit broke a bunch of test cases: https://travis-ci.org/caelum/mamute/builds/33532614.

@monitorjbl
Copy link
Contributor

This is partially my fault, in implementing #37 I included a default mamute.database value in the POM. When you renamed the test/hibernate-mysql.cfg.xml back to test/hibernate.cfg.xml, the value was left in the POM and it's still trying to load hibernate-mysql.cfg.xml.

Delete line 15 in the POM and it should be fixed.

@leocwolter
Copy link
Contributor Author

This is weird, I could run the tests using eclipse. Maybe it will only fail when using mvn tests once the value is on pom, right?

I think the best would be putting it at mamute.properties

@monitorjbl
Copy link
Contributor

I've long since stopped trying to understand Eclipse's weirdness :) I'm able to replicate Travis's results by running mvn clean package from the command line. Does master still build for you from the command line?

@leocwolter
Copy link
Contributor Author

I fixed it with this: 05b2bb1 It was the best I could do from github, but we should move the pom value to mamute.properties to prevent this kind of weirdness :)

@monitorjbl
Copy link
Contributor

The idea at the time was that you could run mvn clean package -Dmamute.database=h2 and choose to build testing against the H2 database instead of MySQL. The problem that you ran into was that there was a default value of mysql for that property in the POM at line 15. Removing the line would have made the default value null so the default file would have been used.

Changing this to be a path to a Hibernate config file would make the code cleaner. I also think putting it in mamute.properties would work, but there's the issue of how to change it at build time so you can test other DBs. Can you have Maven do resource filtering to set the properties file? Maybe have line like this?

mamute.hibernateCfg=${mamute.hibernateCfg}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants