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

The problem with the user's login name #1589

Closed
heiheshang opened this issue Jan 23, 2017 · 25 comments
Closed

The problem with the user's login name #1589

heiheshang opened this issue Jan 23, 2017 · 25 comments

Comments

@heiheshang
Copy link
Contributor

If username = email, you can not change the password. Admin crashes when you try to change your password. There is a restart. I am using the latest version 1.0

@mworrell mworrell added this to the 1.0 milestone Jan 23, 2017
@mworrell
Copy link
Member

Where do you try to change the password? On the page where you edit the person or on the page with the list of usernames?

@heiheshang
Copy link
Contributor Author

I tried both options

@mworrell
Copy link
Member

Do you have the newest master? I just tried and can't reproduce the problem.

@heiheshang
Copy link
Contributor Author

I use postgresql 9.4 can be a problem?

@mworrell
Copy link
Member

Shouldn't be a problem, if it was then you should get sql errors.
I asked @ddeboer to check if he can reproduce the problem on his dev env.

@heiheshang
Copy link
Contributor Author

I see a problem in the module mod_admin_identity action action_admin_identity_dialog_set_username_password.erl.
message
{submit,set_username_password,<<"u4t9mpfuobc7-form">>,<<"u4t9mpfuobc7-form">>}
event(#submit{message=set_username_password},Context)
It leads to a drop node

@mworrell
Copy link
Member

Do you have a longer traceback of the error?

@heiheshang
Copy link
Contributor Author

nor any error does not occur, I tried to put ?DEBUG, but the message does not appear in the console.probably need to do debugging for another

@mworrell
Copy link
Member

If the message does not appear then the crash might be at a different spot.

We still couldn't reproduce the issue :(

@heiheshang
Copy link
Contributor Author

docker can give way to test

@mworrell
Copy link
Member

Docker? Might it be that you are having this issue? #1490

@heiheshang
Copy link
Contributor Author

heiheshang commented Jan 30, 2017

how to use it ?
I'm using vps 1cpu

@mworrell
Copy link
Member

@heiheshang can you try with a 2 cpu instance?

@heiheshang
Copy link
Contributor Author

what for ? I want to save money

@mworrell
Copy link
Member

mworrell commented Jan 30, 2017

I think this is an issue with the scheduler and only having a single scheduler/cpu.

@heiheshang if you can't up the core count, then maybe start erl with more than 1 scheduler:

erl -smp +S 2

See http://erlang.org/doc/man/erl.html

@ddeboer and @mmzeeman do you know the status of #1490 and if that might explain what is reported here?

@mmzeeman
Copy link
Member

The bcrypt nif can't be used with a non-smp erlang. It won't compile. There is a port version of the same algorithm which should work though.

@mmzeeman
Copy link
Member

For the above, see: https://github.com/smarkets/erlang-bcrypt#configuration

Setting mechanism to 'port' might work.

@mworrell
Copy link
Member

Should that be standard or is using the NIF better?

@mmzeeman
Copy link
Member

Good one. The NIF has no limit on the number of simultaneous bcrypt operation, the port version does.

We don't have to do it for speed, because bcrypt was designed to be slow anyhow.

@heiheshang
Copy link
Contributor Author

in zotonic you can set the parameters without changing the container docker ? I can use for this purpose erlang.config ?

@mmzeeman
Copy link
Member

Yes, if you put this in your erlang.config

{bcrypt,
    [{mechanism, port}, {pool_size, 4}]
 },

It will use the port version. This worked fine over here on zotonic stable.

@mworrell
Copy link
Member

@mmzeeman what is the throughput of the port version? We might want to make it the default option if there is not problem with Erlang 19 (or later) and the overall performance.

@mmzeeman
Copy link
Member

Bcrypt is designed to be slow. The pool size defines how many bcrypt operations can be done in parallel. This must be proportional to the expected traffic. The nif version starts an os-level thread and queues bcrypt operations to a single thread. My guess is that the port version is better for a busy server.

@mworrell
Copy link
Member

That was also the gut-feeling I got. Good to have some back-pressure by limiting the number of parallel operations. I will change this default in the master and 0.x

@mworrell
Copy link
Member

Assuming the issue is indeed bcrypt, the issue is further discussed in #1490

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

No branches or pull requests

3 participants