search

ubc / compair

ComPAIR: a peer review application pairing student answers for deeper learning through comparison of peer work
http://ubc.github.io/compair
GNU General Public License v3.0
36 stars 11 forks source link

Remove password generation when there is no password specified in the import csv file #374

Closed xcompass closed 8 years ago

xcompass commented 8 years ago

Encrypting passwords take long time. When there is no password specified in the import file, we can skip generating passwords and encrypting them. It will make importing a lot faster.

xcompass commented 8 years ago

Also we may want to consider put importing user into background task in the future. If there are passwords specified and a lot of users, it may take very long time to complete the task.

lenglund commented 8 years ago

Note: some overlap with #181.

andrew-gardener commented 8 years ago

390 addresses the main issue (set password to null on import if password not set) but doesn't address moving the password hashing for preset passwords to a background job.

From a few quick tests I did with 1000 new users (to the system), CWL import and ComPAIR import with no password takes about 4 seconds. ComPAIR import with preset passwords takes over 60 seconds (nginx timed out on me but the import completed successfully).

Based on this, I think its worth implementing the background task for password hashing on import.

Also it might be worth removing the password field from the import and using a more context aware default (student# then username if not present for example) so that instructors don't have to worry about passwords as much and system admins won't have to generate passwords on request if instructors leave the password blank. It would be less secure though.

xcompass commented 8 years ago

Could you investigate how complex to add background tasks? Celery might be one of the choice. Does it run under a separate process? Any other component might be benefit from this?

andrew-gardener commented 8 years ago

Celery seems like the easiest to implement code base wise. Can use same code base as a Flask app and doesn't require very much configuration/setup (at face value)

Celery runs under a separate process and has some additional dependencies for managing the job queue (RabbitMQ or Redis. Could use SQLAlchemy but reportedly very buggy so it isn't recommended). https://hub.docker.com/_/celery/ has some details about setup for docker (seems easy to setup for development at least).

Other tasks that can benefit from this are: