Username should be unique about mamute

[csokol]

Why?

Chico Sokol

On Thu, Aug 21, 2014 at 12:52 PM, Leonardo Cesar Wolter <
[email protected]> 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]

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]

:-(

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 <
[email protected]> 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]

I guess we can just validate the new users from now

[defaultbr]

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

[monitorjbl]

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

[monitorjbl]

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]

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]

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]

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]

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}