Google Auth account linking still requires password entry for user in database

[agramian]

In order to log in with a google account, there must be user with a matching email address already present in the database. The TCDB and Google accounts are then linked after the first log in attempt.

When creating a user through the web UI, it requires you to enter a password. This becomes an issue if you want to create accounts for other people without making them come and manually enter their password or send it to you. I tried to get around the issue by manually adding a user into the database. The problem there is that after the accounts are linked and the google callback is executed, TestCaseDB just returns to the login page with no flash message or indication of why it has not logged in.

[joffems]

This is an issue that needs to be tackled. I have a few ideas on how to implement solutions and I'm open comments, requests and suggestions. Ideally, I'd like to get several of the items coded, but it may be beneficial to prioritize the work:

1. Create Your Password Email
   • Create a mechanism that let's an admin create a user without a password. This will send an emailto the new user with a link that let's the user create a password.
2. Email random password
   • Let the admin create users without a password. A random password would then be generated and emailed to the user.
   • I am not a big fan of this technique, but if there is a major desire for the option and can make it a configurable option.
3. Self Sign Up
   • Generally, I've been ignoring this feature. It just didn't seem like something that was necessary and would have the potential to give access to data that people want to hide.
   • If implemented, I would include a default user profile of what the user can access.

@agramian, would solution 1 work for you?

[agramian]

@joffems First of all I greatly appreciate the quick response and I am very impressed with TestCaseDB in general. I can't believe it is not a more well known project.

After spending several weeks investigating testing tools, the only test management solution I was decently happy with was Testia Tarantula. After I began modifying it to be more suitable for our purposes I became quite frustrated and luckily found that someone posted a link to testcasedb in the tarantula github issues. I've modified a great deal of TestCaseDB especially regarding the webapi portion which I have interfaced with Buildbot for an extremely powerful automated testing solution.

Honestly, if the scheduler and automation aspects of TestCaseDB were a little better I could see using it alone for all automation and CI purposes. I'm not sure how active this project is but I would be happy to help you and whoever else is involved to take this to the next level.

Back to this specific issue...

It seems that most of your suggestions involve an email which I don't think is even necessary.

The self sign-up is not ideal in my opinion because a test tool like this will mostly be limited to a specific set of users and not a general audience anyway.

When I think of google auth or other oauth login services I think of those as replacing the account specific to that site. So my understanding of the google oauth for TestCaseDB was that it should just replace the TCDB account. Why would anyone alternate sometimes logging in through the TestCaseDB form and other times through Google? The whole point is to not have yet another login account for a user to remember.

The way I think it should work is:

1. The admin user is able to create an account through the Web UI without a password. Maybe there is a checkbox or something indicating that this new user will intend to link to google so the internal password check is bypassed. The internal implementation of TCDB can create a random password which will never be seen by anyone or that will be erased upon the user's first login. The user will only be able to login through google auth.
2. An excel sheet, csv file, or other simple text file list can be used to manage a large amount of users. The file is uploaded to testcasedb which runs sql queries on it to create/update user info. This way the admin will not have to create accounts one-by-one initially. (I am currently doing this with a python script running sql commands against the database)

So that's my intuition of how this feature should work. Because you understand the project better than me and all it's aspects including security you probably have a better idea of how to implement it and achieve this. I look forward to hearing back on this.

[joffems]

Thanks for the general feedback. Improving automation is one of my major goals. I don't see a fork of TestCaseDB on your git page. IF you're willing to share that would be great. If you're interested in helping out, please email me at mjoffe@msjit.ca.

For the current user issues:

1. I can definitely adjust the code so you can create users without passwords. These users will have to use Google oAuth to login. The change should be pretty simple.
2. For the user import, this is also doable. I'll take a look at adding this later on in the week.

[kirantpatil]

@agramian, it was me who posted in Tarantula issues to bring awareness about TestCaseDB and we also would like to make Testcasedb the next generation testing tool. Great to see your presence and energy which is very much required for the nurishment of this project.

We have a junior engineers who have just begun to tinker and we need the mentor so that they can accelerate the development work.

[joffems]

@agramian Fix for blank passwords has been pushed.

Users with blank passwords cannot login with password based authentication, but can login using Google Auth.

I still need to implement the excel import of users.

[agramian]

@joffems It seems to work however the behavior remains the same as before (just returns to the login page) if the single_access_token and persistence_tokens are NULL for the user in the database. In my case since I used a python script to initially enter all the user's in the database, the only way I have found to get it working is to login in as the admin, click to edit a user, and click update user so that the two tokens are generated.

Once you have the excel import this will not be a problem of course.

[joffems]

If you do the initial import using the Rails console instead of Python, the issue should disappear. Of course, once the Excel import is ready it won't be a big deal.

[joffems]

@agramian Ability to import users has been committed. Please check it out.

[agramian]

@joffems small mistake. The import users page legend says "Test Case Upload" instead of something like "Import Users"

[joffems]

@agramian Good catch. Fix has been pushed.

[agramian]

The user import crashes if no file is chosen or the file extension is invalid. It should re-render the import form with an error instead.

[agramian]

@joffems is it possible to add extra options in the import users page to allow updating/overwriting user info? Currently if the user already exists it displays an error message. My thought is if update is checked, then if the user already exists the info is overwritten. Also some other option such as "overwrite all users" should allow removal of users if they don't exist in the uploaded user list. The admin account should be excluded so it can never be removed by this procedure.