search

taa176 / web

Website. Welcome.
0 stars 0 forks source link

replace_db_2 -- Login Bug #7

Closed zeumai closed 5 years ago

zeumai commented 5 years ago

Hey, guys. I started a second branch to make sure I was keeping abreast (aboob) of all your commits. I'm going to bed now, but I have it very close to working; the New User page does, in fact, add a new user to the MySQL database, and the refactored "authorizeLogin" function does correctly compare the password you enter to what's in the database (or so I believe; you get a failure message if you enter the wrong password, and no message if you enter the right one). I must have screwed something up, though, because I can't actually get past the login page.

I'll try to fix the problem tomorrow, but in the meantime if you would like to take a look at it, go ahead. Before you start the site, just run "rebuild_db.js" to delete the old database and replace it with the latest version.

zeumai commented 5 years ago

I fixed this.

taa176 commented 5 years ago

I tested this quickly, and it seems to work well for me. Thanks!

I'll try to look at it more in-depth later today. I do have a question, though. Let's say we notice most of our users are white, and we want to promote diversity on our website. We might want to store the race of all new users and only allow a new white user once, say, three new black users sign up to our site.

How hard would it be to implement this? That is, how flexible is the database? Could we write some kind of javascript API to automatically change the database as we see fit, or does this require the database to be rebuilt and the mysql file rewritten? I'd also like to store the comments in the database at some point. How hard would it be to do that?

zeumai commented 5 years ago

We could certainly write something in Javascript to allow us to alter the database, bearing in mind of course that certain fields (username, password, chatroom) should not be available for tampering because they are already in use in the code. Just adding a field and a trigger, which is what your diversity scheme would require, wouldn't be a problem. We would need to take the site offline while we made the changes to make sure that no one had a lock on the table we were altering.

When it comes to storing the comments, are you referring to the chatroom messages? If so, take a look at my pull request; I've implemented the message logging functions using the MySQL database for storage.