Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016/E1690 Improvements to password recovery and repeated login failures

2016-12-05T16:00:09Z

Fluan: /* Registration */

==E1690 Improvements to password recovery and repeated login failures==

This wiki page is for the description of changes made under E1690 FinalProject for Fall 2016, CSC/ECE 517.

__TOC__

===Background===

Expertiza is an Open Source web application developed on Ruby On Rails platform. It is a platform which allows students to access assignments posted by the course instructor. Expertiza also allows students to select assignment topics, form teams and submit their work. It also allows them to review other students' submissions and improve their work based on the feedback provided. The instructor can look at the feedback provided by students and rate the student based on feedback provided for others work.
It helps organize and upload assignments and reducing the manual review process and helps students provide a peer feedback and also learn from reviewed work. Teams can be chosen by the student or can be assigned automatically based on a priority list inputted alongside each topic available for the assignment.

===Project Description===

Our final project consists of two cases of the password recovery process. Use case 1, Currently, when a user forgets his/her password and wants to reset the password, Expertiza system randomly generates a new password and sends the password as plain text in a email. It is normally considered as a bad practice to send passwords as paint text. We are replacing this practice by sending a reset password link that expires after a certain amount of time. Use case 2 deals with when a user enters wrong credentials. Currently, the login page simply shows an error. Irrespective of the number of times that a user enters wrong login credentials, the system produces a general error message. We are going to be replacing this system by using the alternative 2, using a captcha to verify that the user is indeed a human and not a bot trying to run a brute force attack on the system. This will add the needed layer of security and should serve as a great solution. Below are more details of our implementation.

===Files Created/Modified===
As a part of the project the files mentioned below were the ones, created/modified as needed.
* auth_controller.rb
* password_retrieval_controller.rb
* password_reset.rb (model)
* reset_password.html.erb (view)

===Implementation===
We have implemented the new password recovery system by sending a reset password link to the user's email. This link will be comprised of a generated path to a newly created view for resetting the password with a uniquely randomly generated token. This parameter will be a string attribute of a new model reset_password. This link will expire after a given amount of time. Using logic to compare the createdAt timestamp as well as the current time, the application would decide if the token is expired or not.

We are also implementing a backoff system that will require the user to complete a smart captcha after 3 failed attempts. This smart captcha will be generated through Recaptcha gem and the user will then be redirected to the login page after successfully changing the password. This will ensure that the system is not vulnerable to Brute Force attacks as well as bots.

==Password Reset==

===Model Schema===
Model: password_reset.rb

Attributes
*-id(autogenerated) -integer
*-unique_tokenhash -String
*-createdAt (autogenerated) -timestamp
*-user_email -string

'''Model Details'''

When the user clicks on reset password, it will redirect to a view that has an input to enter the email address of the user. Reset password button will generate a random token (Long string) which will be hashed and saved in the database of the model reset_password. An expiration date will be generated and saved along with the user_id by looking up the user table using email id. The unhashed Token value will be appended on the url emailed to the user for the password reset page.

www.expertiza.com/password_edit/check_reset_url?token=ZB71yObR-Tdssg-@#%

On clicking the url, the link will take you to password_retrieval_controller that will direct you to a reset page. Before redirecting , the controller checks the parameters in the link (username and token) and makes sure that token username pair exists and not expired. Token from the params will be hashed again and checked with the DB. This prevents an attacker who has read access to the database from making a token for some other user, reading the value that was sent in the email, then sending the same value himself. Once the controller completes all the necessary checks, it will redirect to a reset password page for that specific user (based on the user_id / username)

Each Email Address can have only one active token saved in the database. Every time a new token is generated, it will replace the existing one which ensures that only one reset link is available. Also, this will make sure that DB content of password_reset can never exceed the number of users registered in the application. This eliminates the need to clear out expired Tokens.

[[File:Capture password reset.JPG]]

==Captcha==

The project will be using reCAPTCHA gem. reCAPTCHA is a free service from Google that helps protect websites from spam and abuse. A “CAPTCHA” is a test to tell humans and robot apart. This kind of service is important for websites or web applications with lots of user generated content. The test is easy for a human to solve, but hard for bots and other malicious software to figure out.

After 3 failed Login attempts, a captcha would appear to make sure that a bot or a malicious software is not trying to attempt login using brute force.

[[File:Captcha.png]]

==== Gem File ====
Adding this line to the Gem file allows us to have access to the recaptcha gem.

<pre>gem "recaptcha", require: "recaptcha/rails"</pre>

====Registration====
To let reCAPTCHA work normally, we need to register the domains that the project will be deployed on [reCAPTCHA official website][https://www.google.com/recaptcha]. Currently, we can use it on expertiza.com, 0.0.0.0, and localhost. Once the registration is done, two keys will be automatically generated -- site key and secret key. The site key is used in HTML, and the secret key is used for communication between the site and Google.

====Add reCAPTCHA to codes====

To show reCAPTCHA in webpages is easy, all we need to do is add this code to _form.html.erb

<pre><div class="g-recaptcha" data-sitekey="6Lci0wwUAAAAAB69GEpUbEmkIu4frJ8dgqx90o7b"></div></pre>

And, we need to create a recaptcha.rb file into config/initializers folder, which stores our site key and secret key.

<pre>
Recaptcha.configure do |config|
config.site_key = '6Lci0wwUAAAAAB69GEpUbEmkIu4frJ8dgqx90o7b'
config.secret_key = '6Lci0wwUAAAAAIZ***********RNeDD6e84q9XlM'
end
</pre>

==== Backoff System ====
In Auth Controller we added the following code. The variable @@attempts acts as a counter to track the amount of invalid login attempts a user makes. By utilizing the existing login code we were able to place the increment code. Once the attempts variable is greater than or equal to 3 we then force the user to use the recaptcha question in addition to their correct logic credentials. Once the new requirements to login are satisfied the user is redirected to the password retrieval, otherwise they are redirected to the root screen with the captcha question.
<pre>
@@attemps = 0

def login
if request.get?
AuthController.clear_session(session)
else
user = User.find_by_login(params[:login][:name])
if user and user.valid_password?(params[:login][:password])
after_login(user)
else

@@attemps = @@attemps + 1
logger.warn "Failed login attempt."
flash[:error] = "Your username or password is incorrect."
if @@attemps >= 3 ##User entered invalid login credentials at least 3 times
if verify_recaptcha(model: @user)
@@attemps = 0
redirect_to controller: 'password_retrieval', action: 'forgotten'
end

else
redirect_to root_path

end

end
end
end # def login

</pre>

==Testing==

To run the Rspecs test cases:
rspec path_to_expertiza/spec/controllers/password_retrieval_controller_spec.rb

To test from UI:
i) Enter the wrong password on login page three consecutive times, you will shown with Google Captcha for the fourth attempt.
ii) On entering the password, wrong the fourth time you will be redirected to "forgot password" page.
It can also be reached by clicking "forgot password" page on login page.
iii) Enter the email Id, for which new password has to be set. On clicking "Request password" you will get a mail with password reset link.
iv) Clicking on the password reset link, you will be redirected to password reset page where you can set your new password.

Here is a short [http://recordit.co/pXq9jM9xhr video] demonstrating the same.

CSC/ECE 517 Fall 2016/E1690 Improvements to password recovery and repeated login failures

2016-12-05T15:56:57Z

Fluan: /* Captcha */

==E1690 Improvements to password recovery and repeated login failures==

This wiki page is for the description of changes made under E1690 FinalProject for Fall 2016, CSC/ECE 517.

__TOC__

===Background===

Expertiza is an Open Source web application developed on Ruby On Rails platform. It is a platform which allows students to access assignments posted by the course instructor. Expertiza also allows students to select assignment topics, form teams and submit their work. It also allows them to review other students' submissions and improve their work based on the feedback provided. The instructor can look at the feedback provided by students and rate the student based on feedback provided for others work.
It helps organize and upload assignments and reducing the manual review process and helps students provide a peer feedback and also learn from reviewed work. Teams can be chosen by the student or can be assigned automatically based on a priority list inputted alongside each topic available for the assignment.

===Project Description===

Our final project consists of two cases of the password recovery process. Use case 1, Currently, when a user forgets his/her password and wants to reset the password, Expertiza system randomly generates a new password and sends the password as plain text in a email. It is normally considered as a bad practice to send passwords as paint text. We are replacing this practice by sending a reset password link that expires after a certain amount of time. Use case 2 deals with when a user enters wrong credentials. Currently, the login page simply shows an error. Irrespective of the number of times that a user enters wrong login credentials, the system produces a general error message. We are going to be replacing this system by using the alternative 2, using a captcha to verify that the user is indeed a human and not a bot trying to run a brute force attack on the system. This will add the needed layer of security and should serve as a great solution. Below are more details of our implementation.

===Files Created/Modified===
As a part of the project the files mentioned below were the ones, created/modified as needed.
* auth_controller.rb
* password_retrieval_controller.rb
* password_reset.rb (model)
* reset_password.html.erb (view)

===Implementation===
We have implemented the new password recovery system by sending a reset password link to the user's email. This link will be comprised of a generated path to a newly created view for resetting the password with a uniquely randomly generated token. This parameter will be a string attribute of a new model reset_password. This link will expire after a given amount of time. Using logic to compare the createdAt timestamp as well as the current time, the application would decide if the token is expired or not.

We are also implementing a backoff system that will require the user to complete a smart captcha after 3 failed attempts. This smart captcha will be generated through Recaptcha gem and the user will then be redirected to the login page after successfully changing the password. This will ensure that the system is not vulnerable to Brute Force attacks as well as bots.

==Password Reset==

===Model Schema===
Model: password_reset.rb

Attributes
*-id(autogenerated) -integer
*-unique_tokenhash -String
*-createdAt (autogenerated) -timestamp
*-user_email -string

'''Model Details'''

When the user clicks on reset password, it will redirect to a view that has an input to enter the email address of the user. Reset password button will generate a random token (Long string) which will be hashed and saved in the database of the model reset_password. An expiration date will be generated and saved along with the user_id by looking up the user table using email id. The unhashed Token value will be appended on the url emailed to the user for the password reset page.

www.expertiza.com/password_edit/check_reset_url?token=ZB71yObR-Tdssg-@#%

On clicking the url, the link will take you to password_retrieval_controller that will direct you to a reset page. Before redirecting , the controller checks the parameters in the link (username and token) and makes sure that token username pair exists and not expired. Token from the params will be hashed again and checked with the DB. This prevents an attacker who has read access to the database from making a token for some other user, reading the value that was sent in the email, then sending the same value himself. Once the controller completes all the necessary checks, it will redirect to a reset password page for that specific user (based on the user_id / username)

Each Email Address can have only one active token saved in the database. Every time a new token is generated, it will replace the existing one which ensures that only one reset link is available. Also, this will make sure that DB content of password_reset can never exceed the number of users registered in the application. This eliminates the need to clear out expired Tokens.

[[File:Capture password reset.JPG]]

==Captcha==

The project will be using reCAPTCHA gem. reCAPTCHA is a free service from Google that helps protect websites from spam and abuse. A “CAPTCHA” is a test to tell humans and robot apart. This kind of service is important for websites or web applications with lots of user generated content. The test is easy for a human to solve, but hard for bots and other malicious software to figure out.

After 3 failed Login attempts, a captcha would appear to make sure that a bot or a malicious software is not trying to attempt login using brute force.

[[File:Captcha.png]]

==== Gem File ====
Adding this line to the Gem file allows us to have access to the recaptcha gem.

<pre>gem "recaptcha", require: "recaptcha/rails"</pre>

====Registration====
To let reCAPTCHA work normally, we need to register the domains that the project will be deployed on reCAPTCHA official website. Currently, we can use it on expertiza.com, 0.0.0.0, and localhost. Once the registration is done, two keys will be automatically generated -- site key and secret key. The site key is used in HTML, and the secret key is used for communication between the site and Google.

====Add reCAPTCHA to codes====

To show reCAPTCHA in webpages is easy, all we need to do is add this code to _form.html.erb

<pre><div class="g-recaptcha" data-sitekey="6Lci0wwUAAAAAB69GEpUbEmkIu4frJ8dgqx90o7b"></div></pre>

And, we need to create a recaptcha.rb file into config/initializers folder, which stores our site key and secret key.

<pre>
Recaptcha.configure do |config|
config.site_key = '6Lci0wwUAAAAAB69GEpUbEmkIu4frJ8dgqx90o7b'
config.secret_key = '6Lci0wwUAAAAAIZ***********RNeDD6e84q9XlM'
end
</pre>

==== Backoff System ====
In Auth Controller we added the following code. The variable @@attempts acts as a counter to track the amount of invalid login attempts a user makes. By utilizing the existing login code we were able to place the increment code. Once the attempts variable is greater than or equal to 3 we then force the user to use the recaptcha question in addition to their correct logic credentials. Once the new requirements to login are satisfied the user is redirected to the password retrieval, otherwise they are redirected to the root screen with the captcha question.
<pre>
@@attemps = 0

def login
if request.get?
AuthController.clear_session(session)
else
user = User.find_by_login(params[:login][:name])
if user and user.valid_password?(params[:login][:password])
after_login(user)
else

@@attemps = @@attemps + 1
logger.warn "Failed login attempt."
flash[:error] = "Your username or password is incorrect."
if @@attemps >= 3 ##User entered invalid login credentials at least 3 times
if verify_recaptcha(model: @user)
@@attemps = 0
redirect_to controller: 'password_retrieval', action: 'forgotten'
end

else
redirect_to root_path

end

end
end
end # def login

</pre>

==Testing==

To run the Rspecs test cases:
rspec path_to_expertiza/spec/controllers/password_retrieval_controller_spec.rb

To test from UI:
i) Enter the wrong password on login page three consecutive times, you will shown with Google Captcha for the fourth attempt.
ii) On entering the password, wrong the fourth time you will be redirected to "forgot password" page.
It can also be reached by clicking "forgot password" page on login page.
iii) Enter the email Id, for which new password has to be set. On clicking "Request password" you will get a mail with password reset link.
iv) Clicking on the password reset link, you will be redirected to password reset page where you can set your new password.

Here is a short [http://recordit.co/pXq9jM9xhr video] demonstrating the same.

CSC/ECE 517 Fall 2016/E1666. Test team functionality

2016-11-05T02:11:08Z

Fluan: /* Result */

== Background ==
Expertiza is an open source web based peer review system developed and maintained by students and faculty at North Carolina State University. It enables students enrolled in a particular course to form online teams and complete assignments. A typical cycle of an assignment involves the following major steps:

* A pool of topics is made available to the students to choose from and form team to complete it within a pre-set deadline.
* After the development phase is finished, begins the peer review phase. Here students can review work of other teams, on the basis of some predefined factors and provide their feedback.
* Members of a team can also provide feedback for the respective review done for their work.
* In some projects there is a second development phase which allows team members to improve upon their work keeping past reviews in consideration.
* After this second development cycle begins another review phase, where original reviewers can re-review the updated work and provide critical feedback.

== Purpose ==
The purpose of this task is to write functional tests for team functionality. Once an assignment is out, a student can select this assignment and others can join in the team. To test this functionality we wrote functional tests for the various scenarios.
One such scenario is :

* Once the assignment is out and a student selects it, he/she can send out invites to other students to join the team.
* Invited students can accept the invitation and join the team.

== Functional Tests ==

Functional tests ensure that the functionalities of a software system are working as expected. To write our functional tests, we used the Capybara gem available for Ruby.
Capybara gem allows a user to test their web application through simulations.

== Functional Tests Implementation ==

=== Functional Tests for accepting an invitation ===

In Expertiza assignments, the only way for a student to join an existing team is to be invited by the leader. Therefore, we will test whether the invitation function run smoothly. But before the test, we need to initialize some information.

<pre>
before(:each) do
create(:assignment, name: "TestTeam", directory_path: 'test_team')
create_list(:participant, 3)
create(:assignment_node)
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create(:assignment_due_date, deadline_type: DeadlineType.where(name: 'review').first, due_at: Time.now + (100 * 24 * 60 * 60))
#create(:topic)
create(:topic, topic_name: "work1")
end
</pre>

Here, we created a team, and set the maximum students to 3. Because there can only be one student in each session of browser, we need to create different sessions for different students. The first session is for the leader who will be the first one who select this topic.

<pre>
it "case1" do
in_browser(:one) do
#test log in as a student
user = User.find_by_name('student2064')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }
visit root_path
fill_in 'login_name', with: 'student2064'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

expect(page).to have_content "User: student2064"
expect(page).to have_content "TestTeam"

click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"

#test if the topic can be seen and chosen by a student
click_link "Signup sheet"
expect(page).to have_content "work1"
my_link = find(:xpath, "//a[contains(@href,'sign_up_sheet/sign_up?assignment_id=#{Assignment.last.id}&id=1')]")
my_link.click

#test after selecting a topic, a team formed
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Team Name"
expect(page).to have_content "student2064"

#test if a team leader can invite another student
page.fill_in 'user_name', :with => 'student2065'
click_button('Invite')
expect(page).to have_content "Sent invitations"
expect(page).to have_content "student2065"
end
</pre>

So far, a team has been created by ‘student2064’, who is the leader. Then, we will let him send an invitation to another user ‘student2065’. Now, let’s create a new session which allows ’student2065’ to log in. After the login, we need to test if he receive the invitation and if he accepts it, whether or not he will be in the team. If he is included in the team, he will be able to see the name of the leader, who is ‘student2064’.

<pre>
in_browser(:two) do
visit '/'
user = User.find_by_name('student2065')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }

visit root_path
fill_in 'login_name', with: 'student2065'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#test if a student can see an invitation
expect(page).to have_content "User: student2065"
expect(page).to have_content "TestTeam"
click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Received Invitations"
expect(page).to have_content "student2064"

#test if a student can accept an invitation
click_link "Accept"
expect(page).to have_content "Team Information"
expect(page).to have_content "Team members"
expect(page).to have_content "Edit name "
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
expect(page).to have_content "Leave team"
end
</pre>

===Functional Tests for rejecting an invitation===

Same as the previous one, we set up the information at the beginning, and then let ‘student2064’ to pick up a topic and send an invitation to ‘student2065’. This time, we will let ‘student2065’ to choose to reject this invitation. If he declines the invitation, the invitation will disappear.
<pre>
#test if a student can decline an invitation
click_link "Decline"
expect(page).to have_no_content "Received Invitations"
</pre>

===Functional Tests for sending an invitation by a team member===

Same as the first case, we let ‘student2064’ to pick up a topic and send an invitation to ‘student2065’. Then, ‘student2065’ accepts the invitation and becomes a team member. Now we test if ‘student2065’ can send an invitation to another student—‘student2066’.

<pre>
#invite another student
page.fill_in 'user_name', :with => 'student2066'
click_button('Invite')
expect(page).to have_content "Sent invitations"
expect(page).to have_content "student2066"
</pre>

Now, let’s create the third session and login as ‘student2066’. If the invitation sent by ‘student2065’ is successful, ‘student2066’ should be able to see an ‘Received Invitation’ by ‘student2065’ in ‘Your Team’ page.
<pre>
in_browser(:three) do
visit '/'
#login as student2065
user = User.find_by_name('student2066')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }
visit root_path
fill_in 'login_name', with: 'student2066'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#test if a student can see an invitation
expect(page).to have_content "User: student2066"
expect(page).to have_content "TestTeam"
click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Received Invitations"
expect(page).to have_content "student2065"
#test if a student can accept an invitation
click_link "Accept"
expect(page).to have_content "Team Information"
expect(page).to have_content "Team members"
expect(page).to have_content "Edit name "
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
expect(page).to have_content "student2066"
expect(page).to have_content "Leave team"
end
</pre>

===Functional Tests for leaving a team by a team member===

Everything is same to the first case except the last two lines of codes. In the last two lines, we let ‘student2065’ to leave the team, if he really leaves, he will see “You no longer have a team” in the next page.

<pre>
click_link "Leave team"
expect(page).to have_content "You no longer have a team! "
</pre>

===Functional Tests for leaving a team by a team leader===

Everything is same to the first case before we change back to session one. If ‘student2064’ (Team leader) clicks “Leave team”, he should see “You no longer have a team” in the next page.
<pre>
in_browser(:one) do
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
click_link "Leave team"
expect(page).to have_content "You no longer have a team! "
end
</pre>

===Functional Tests for whether students choosing the same topic are in the same team===

Since the only way for students to be in a team is by invitation, students who choose the same topic will be in different team. Our test is to let two different students select the same topic and see if their teammates contains each other. Therefore, first we let ‘student2064’ and 'student2065' sign for the same topic, and in their pages, to see if there is 'student2065' or 'student2064'.

<pre>
expect(page).to have_content "Team Name"
expect(page).to have_content "student2065"
expect(page).to have_content "student2064"
</pre>

== Running the tests ==

The tests can be run on the terminal using the command:
<pre>
rspec team_functionality_spec.rb
</pre>

Whether the test fails or succeeds, allows us to determine which parts of the system are functioning properly.

== Result ==
[[File:new1.PNG|200px|Image: 200 pixels]]

[[File:new2.PNG|200px|Image: 200 pixels]]

== External Links ==
# link for forked repository [[https://github.com/hli36/expertiza.git]]
# Github link for original repository [[https://github.com/expertiza/expertiza.git]]
# Github link for Capybara [[https://github.com/jnicklas/capybara.git]]

CSC/ECE 517 Fall 2016/E1666. Test team functionality

2016-11-05T02:09:33Z

Fluan:

== Background ==
Expertiza is an open source web based peer review system developed and maintained by students and faculty at North Carolina State University. It enables students enrolled in a particular course to form online teams and complete assignments. A typical cycle of an assignment involves the following major steps:

* A pool of topics is made available to the students to choose from and form team to complete it within a pre-set deadline.
* After the development phase is finished, begins the peer review phase. Here students can review work of other teams, on the basis of some predefined factors and provide their feedback.
* Members of a team can also provide feedback for the respective review done for their work.
* In some projects there is a second development phase which allows team members to improve upon their work keeping past reviews in consideration.
* After this second development cycle begins another review phase, where original reviewers can re-review the updated work and provide critical feedback.

== Purpose ==
The purpose of this task is to write functional tests for team functionality. Once an assignment is out, a student can select this assignment and others can join in the team. To test this functionality we wrote functional tests for the various scenarios.
One such scenario is :

* Once the assignment is out and a student selects it, he/she can send out invites to other students to join the team.
* Invited students can accept the invitation and join the team.

== Functional Tests ==

Functional tests ensure that the functionalities of a software system are working as expected. To write our functional tests, we used the Capybara gem available for Ruby.
Capybara gem allows a user to test their web application through simulations.

== Functional Tests Implementation ==

=== Functional Tests for accepting an invitation ===

In Expertiza assignments, the only way for a student to join an existing team is to be invited by the leader. Therefore, we will test whether the invitation function run smoothly. But before the test, we need to initialize some information.

<pre>
before(:each) do
create(:assignment, name: "TestTeam", directory_path: 'test_team')
create_list(:participant, 3)
create(:assignment_node)
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create(:assignment_due_date, deadline_type: DeadlineType.where(name: 'review').first, due_at: Time.now + (100 * 24 * 60 * 60))
#create(:topic)
create(:topic, topic_name: "work1")
end
</pre>

Here, we created a team, and set the maximum students to 3. Because there can only be one student in each session of browser, we need to create different sessions for different students. The first session is for the leader who will be the first one who select this topic.

<pre>
it "case1" do
in_browser(:one) do
#test log in as a student
user = User.find_by_name('student2064')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }
visit root_path
fill_in 'login_name', with: 'student2064'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

expect(page).to have_content "User: student2064"
expect(page).to have_content "TestTeam"

click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"

#test if the topic can be seen and chosen by a student
click_link "Signup sheet"
expect(page).to have_content "work1"
my_link = find(:xpath, "//a[contains(@href,'sign_up_sheet/sign_up?assignment_id=#{Assignment.last.id}&id=1')]")
my_link.click

#test after selecting a topic, a team formed
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Team Name"
expect(page).to have_content "student2064"

#test if a team leader can invite another student
page.fill_in 'user_name', :with => 'student2065'
click_button('Invite')
expect(page).to have_content "Sent invitations"
expect(page).to have_content "student2065"
end
</pre>

So far, a team has been created by ‘student2064’, who is the leader. Then, we will let him send an invitation to another user ‘student2065’. Now, let’s create a new session which allows ’student2065’ to log in. After the login, we need to test if he receive the invitation and if he accepts it, whether or not he will be in the team. If he is included in the team, he will be able to see the name of the leader, who is ‘student2064’.

<pre>
in_browser(:two) do
visit '/'
user = User.find_by_name('student2065')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }

visit root_path
fill_in 'login_name', with: 'student2065'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#test if a student can see an invitation
expect(page).to have_content "User: student2065"
expect(page).to have_content "TestTeam"
click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Received Invitations"
expect(page).to have_content "student2064"

#test if a student can accept an invitation
click_link "Accept"
expect(page).to have_content "Team Information"
expect(page).to have_content "Team members"
expect(page).to have_content "Edit name "
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
expect(page).to have_content "Leave team"
end
</pre>

===Functional Tests for rejecting an invitation===

Same as the previous one, we set up the information at the beginning, and then let ‘student2064’ to pick up a topic and send an invitation to ‘student2065’. This time, we will let ‘student2065’ to choose to reject this invitation. If he declines the invitation, the invitation will disappear.
<pre>
#test if a student can decline an invitation
click_link "Decline"
expect(page).to have_no_content "Received Invitations"
</pre>

===Functional Tests for sending an invitation by a team member===

Same as the first case, we let ‘student2064’ to pick up a topic and send an invitation to ‘student2065’. Then, ‘student2065’ accepts the invitation and becomes a team member. Now we test if ‘student2065’ can send an invitation to another student—‘student2066’.

<pre>
#invite another student
page.fill_in 'user_name', :with => 'student2066'
click_button('Invite')
expect(page).to have_content "Sent invitations"
expect(page).to have_content "student2066"
</pre>

Now, let’s create the third session and login as ‘student2066’. If the invitation sent by ‘student2065’ is successful, ‘student2066’ should be able to see an ‘Received Invitation’ by ‘student2065’ in ‘Your Team’ page.
<pre>
in_browser(:three) do
visit '/'
#login as student2065
user = User.find_by_name('student2066')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }
visit root_path
fill_in 'login_name', with: 'student2066'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#test if a student can see an invitation
expect(page).to have_content "User: student2066"
expect(page).to have_content "TestTeam"
click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Received Invitations"
expect(page).to have_content "student2065"
#test if a student can accept an invitation
click_link "Accept"
expect(page).to have_content "Team Information"
expect(page).to have_content "Team members"
expect(page).to have_content "Edit name "
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
expect(page).to have_content "student2066"
expect(page).to have_content "Leave team"
end
</pre>

===Functional Tests for leaving a team by a team member===

Everything is same to the first case except the last two lines of codes. In the last two lines, we let ‘student2065’ to leave the team, if he really leaves, he will see “You no longer have a team” in the next page.

<pre>
click_link "Leave team"
expect(page).to have_content "You no longer have a team! "
</pre>

===Functional Tests for leaving a team by a team leader===

Everything is same to the first case before we change back to session one. If ‘student2064’ (Team leader) clicks “Leave team”, he should see “You no longer have a team” in the next page.
<pre>
in_browser(:one) do
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
click_link "Leave team"
expect(page).to have_content "You no longer have a team! "
end
</pre>

===Functional Tests for whether students choosing the same topic are in the same team===

Since the only way for students to be in a team is by invitation, students who choose the same topic will be in different team. Our test is to let two different students select the same topic and see if their teammates contains each other. Therefore, first we let ‘student2064’ and 'student2065' sign for the same topic, and in their pages, to see if there is 'student2065' or 'student2064'.

<pre>
expect(page).to have_content "Team Name"
expect(page).to have_content "student2065"
expect(page).to have_content "student2064"
</pre>

== Running the tests ==

The tests can be run on the terminal using the command:
<pre>
rspec team_functionality_spec.rb
</pre>

Whether the test fails or succeeds, allows us to determine which parts of the system are functioning properly.

== Result ==
[[File:new1.PNG]]
[[File:new2.PNG]]

== External Links ==
# link for forked repository [[https://github.com/hli36/expertiza.git]]
# Github link for original repository [[https://github.com/expertiza/expertiza.git]]
# Github link for Capybara [[https://github.com/jnicklas/capybara.git]]

File:New2.PNG

2016-11-05T02:08:05Z

Fluan:

File:New1.PNG

2016-11-05T02:07:29Z

Fluan:

CSC/ECE 517 Fall 2016/E1666. Test team functionality

2016-10-28T20:45:27Z

Fluan: /* Functional Tests Implementation */

== Background ==
Expertiza is an open source web based peer review system developed and maintained by students and faculty at North Carolina State University. It enables students enrolled in a particular course to form online teams and complete assignments. A typical cycle of an assignment involves the following major steps:

* A pool of topics is made available to the students to choose from and form team to complete it within a pre-set deadline.
* After the development phase is finished, begins the peer review phase. Here students can review work of other teams, on the basis of some predefined factors and provide their feedback.
* Members of a team can also provide feedback for the respective review done for their work.
* In some projects there is a second development phase which allows team members to improve upon their work keeping past reviews in consideration.
* After this second development cycle begins another review phase, where original reviewers can re-review the updated work and provide critical feedback.

== Purpose ==
The purpose of this task is to write functional tests for team functionality. Once an assignment is out, a student can select this assignment and others can join in the team. To test this functionality we wrote functional tests for the various scenarios.
One such scenario is :

* Once the assignment is out and a student selects it, he/she can send out invites to other students to join the team.
* Invited students can accept the invitation and join the team.

== Functional Tests ==

Functional tests ensure that the functionalities of a software system are working as expected. To write our functional tests, we used the Capybara gem available for Ruby.
Capybara gem allows a user to test their web application through simulations.

== Functional Tests Implementation ==

=== Functional Tests for accepting an invitation ===

In Expertiza assignments, the only way for a student to join an existing team is to be invited by the leader. Therefore, we will test whether the invitation function run smoothly. But before the test, we need to initialize some information.

<pre>
before(:each) do
create(:assignment, name: "TestTeam", directory_path: 'test_team')
create_list(:participant, 3)
create(:assignment_node)
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create(:assignment_due_date, deadline_type: DeadlineType.where(name: 'review').first, due_at: Time.now + (100 * 24 * 60 * 60))
#create(:topic)
create(:topic, topic_name: "work1")
end
</pre>

Here, we created a team, and set the maximum students to 3. Because there can only be one student in each session of browser, we need to create different sessions for different students. The first session is for the leader who will be the first one who select this topic.

<pre>
it "case1" do
in_browser(:one) do
#test log in as a student
user = User.find_by_name('student2064')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }
visit root_path
fill_in 'login_name', with: 'student2064'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

expect(page).to have_content "User: student2064"
expect(page).to have_content "TestTeam"

click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"

#test if the topic can be seen and chosen by a student
click_link "Signup sheet"
expect(page).to have_content "work1"
my_link = find(:xpath, "//a[contains(@href,'sign_up_sheet/sign_up?assignment_id=#{Assignment.last.id}&id=1')]")
my_link.click

#test after selecting a topic, a team formed
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Team Name"
expect(page).to have_content "student2064"

#test if a team leader can invite another student
page.fill_in 'user_name', :with => 'student2065'
click_button('Invite')
expect(page).to have_content "Sent invitations"
expect(page).to have_content "student2065"
end
</pre>

So far, a team has been created by ‘student2064’, who is the leader. Then, we will let him send an invitation to another user ‘student2065’. Now, let’s create a new session which allows ’student2065’ to log in. After the login, we need to test if he receive the invitation and if he accepts it, whether or not he will be in the team. If he is included in the team, he will be able to see the name of the leader, who is ‘student2064’.

<pre>
in_browser(:two) do
visit '/'
user = User.find_by_name('student2065')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }

visit root_path
fill_in 'login_name', with: 'student2065'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#test if a student can see an invitation
expect(page).to have_content "User: student2065"
expect(page).to have_content "TestTeam"
click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Received Invitations"
expect(page).to have_content "student2064"

#test if a student can accept an invitation
click_link "Accept"
expect(page).to have_content "Team Information"
expect(page).to have_content "Team members"
expect(page).to have_content "Edit name "
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
expect(page).to have_content "Leave team"
end
</pre>

===Functional Tests for rejecting an invitation===

Same as the previous one, we set up the information at the beginning, and then let ‘student2064’ to pick up a topic and send an invitation to ‘student2065’. This time, we will let ‘student2065’ to choose to reject this invitation. If he declines the invitation, the invitation will disappear.
<pre>
#test if a student can decline an invitation
click_link "Decline"
expect(page).to have_no_content "Received Invitations"
</pre>

===Functional Tests for sending an invitation by a team member===

Same as the first case, we let ‘student2064’ to pick up a topic and send an invitation to ‘student2065’. Then, ‘student2065’ accepts the invitation and becomes a team member. Now we test if ‘student2065’ can send an invitation to another student—‘student2066’.

<pre>
#invite another student
page.fill_in 'user_name', :with => 'student2066'
click_button('Invite')
expect(page).to have_content "Sent invitations"
expect(page).to have_content "student2066"
</pre>

Now, let’s create the third session and login as ‘student2066’. If the invitation sent by ‘student2065’ is successful, ‘student2066’ should be able to see an ‘Received Invitation’ by ‘student2065’ in ‘Your Team’ page.
<pre>
in_browser(:three) do
visit '/'
#login as student2065
user = User.find_by_name('student2066')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }
visit root_path
fill_in 'login_name', with: 'student2066'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#test if a student can see an invitation
expect(page).to have_content "User: student2066"
expect(page).to have_content "TestTeam"
click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Received Invitations"
expect(page).to have_content "student2065"
#test if a student can accept an invitation
click_link "Accept"
expect(page).to have_content "Team Information"
expect(page).to have_content "Team members"
expect(page).to have_content "Edit name "
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
expect(page).to have_content "student2066"
expect(page).to have_content "Leave team"
end
</pre>

===Functional Tests for leaving a team by a team member===

Everything is same to the first case except the last two lines of codes. In the last two lines, we let ‘student2065’ to leave the team, if he really leaves, he will see “You no longer have a team” in the next page.

<pre>
click_link "Leave team"
expect(page).to have_content "You no longer have a team! "
</pre>

===Functional Tests for leaving a team by a team leader===

Everything is same to the first case before we change back to session one. If ‘student2064’ (Team leader) clicks “Leave team”, he should see “You no longer have a team” in the next page.
<pre>
in_browser(:one) do
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
click_link "Leave team"
expect(page).to have_content "You no longer have a team! "
end
</pre>

===Functional Tests for whether students choosing the same topic are in the same team===

Since the only way for students to be in a team is by invitation, students who choose the same topic will be in different team. Our test is to let two different students select the same topic and see if their teammates contains each other. Therefore, first we let ‘student2064’ and 'student2065' sign for the same topic, and in their pages, to see if there is 'student2065' or 'student2064'.

<pre>
expect(page).to have_content "Team Name"
expect(page).to have_content "student2065"
expect(page).to have_content "student2064"
</pre>

== Running the tests ==

The tests can be run on the terminal using the command:
<pre>
rspec team_functionality_spec.rb
</pre>

Whether the test fails or succeeds, allows us to determine which parts of the system are functioning properly.

== External Links ==
# link for forked repository [[https://github.com/hli36/expertiza.git]]
# Github link for original repository [[https://github.com/expertiza/expertiza.git]]
# Github link for Capybara [[https://github.com/jnicklas/capybara.git]]

CSC/ECE 517 Fall 2016/E1666. Test team functionality

2016-10-28T20:05:16Z

Fluan:

= Feature Tests for Team Functionality =

=== Background ===
Expertiza is an open source web based peer review system developed and maintained by students and faculty at North Carolina State University. It enables students enrolled in a particular course to form online teams and complete assignments. A typical cycle of an assignment involves the following major steps:

* A pool of topics is made available to the students to choose from and form team to complete it within a pre-set deadline.
* After the development phase is finished, begins the peer review phase. Here students can review work of other teams, on the basis of some predefined factors and provide their feedback.
* Members of a team can also provide feedback for the respective review done for their work.
* In some projects there is a second development phase which allows team members to improve upon their work keeping past reviews in consideration.
* After this second development cycle begins another review phase, where original reviewers can re-review the updated work and provide critical feedback.

=== Purpose ===
The purpose of this task is to write functional tests for team functionality. Once an assignment is out, a student can select this assignment and others can join in the team. To test this functionality we wrote functional tests for the various scenarios.
One such scenario is :

* Once the assignment is out and a student selects it, he/she can send out invites to other students to join the team.
* Invited students can accept the invitation and join the team.

=== Functional Tests ===

Functional tests ensure that the functionalities of a software system are working as expected. To write our functional tests, we used the Capybara gem available for Ruby.
Capybara gem allows a user to test their web application through simulations.

=== Functional Tests Implementation ===

=== Functional Tests for accepting an invitation ===

In Expertiza assignments, the only way for a student to join an existing team is to be invited by the leader. Therefore, we will test whether the invitation function run smoothly. But before the test, we need to initialize some information.

<pre>
before(:each) do
create(:assignment, name: "TestTeam", directory_path: 'test_team')
create_list(:participant, 3)
create(:assignment_node)
create(:deadline_type, name: "submission")
create(:deadline_type, name: "review")
create(:deadline_type, name: "metareview")
create(:deadline_type, name: "drop_topic")
create(:deadline_type, name: "signup")
create(:deadline_type, name: "team_formation")
create(:deadline_right)
create(:deadline_right, name: 'Late')
create(:deadline_right, name: 'OK')
create(:assignment_due_date, deadline_type: DeadlineType.where(name: 'review').first, due_at: Time.now + (100 * 24 * 60 * 60))
#create(:topic)
create(:topic, topic_name: "work1")
end
</pre>

Here, we created a team, and set the maximum students to 3. Because there can only be one student in each session of browser, we need to create different sessions for different students. The first session is for the leader who will be the first one who select this topic.

<pre>
it "case1" do
in_browser(:one) do
#test log in as a student
user = User.find_by_name('student2064')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }
visit root_path
fill_in 'login_name', with: 'student2064'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

expect(page).to have_content "User: student2064"
expect(page).to have_content "TestTeam"

click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"

#test if the topic can be seen and chosen by a student
click_link "Signup sheet"
expect(page).to have_content "work1"
my_link = find(:xpath, "//a[contains(@href,'sign_up_sheet/sign_up?assignment_id=#{Assignment.last.id}&id=1')]")
my_link.click

#test after selecting a topic, a team formed
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Team Name"
expect(page).to have_content "student2064"

#test if a team leader can invite another student
page.fill_in 'user_name', :with => 'student2065'
click_button('Invite')
expect(page).to have_content "Sent invitations"
expect(page).to have_content "student2065"
end
</pre>

So far, a team has been created by ‘student2064’, who is the leader. Then, we will let him send an invitation to another user ‘student2065’. Now, let’s create a new session which allows ’student2065’ to log in. After the login, we need to test if he receive the invitation and if he accepts it, whether or not he will be in the team. If he is included in the team, he will be able to see the name of the leader, who is ‘student2064’.

<pre>
in_browser(:two) do
visit '/'
user = User.find_by_name('student2065')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }

visit root_path
fill_in 'login_name', with: 'student2065'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#test if a student can see an invitation
expect(page).to have_content "User: student2065"
expect(page).to have_content "TestTeam"
click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Received Invitations"
expect(page).to have_content "student2064"

#test if a student can accept an invitation
click_link "Accept"
expect(page).to have_content "Team Information"
expect(page).to have_content "Team members"
expect(page).to have_content "Edit name "
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
expect(page).to have_content "Leave team"
end
</pre>

===Functional Tests for rejecting an invitation===

Same as the previous one, we set up the information at the beginning, and then let ‘student2064’ to pick up a topic and send an invitation to ‘student2065’. This time, we will let ‘student2065’ to choose to reject this invitation. If he declines the invitation, the invitation will disappear.
<pre>
#test if a student can decline an invitation
click_link "Decline"
expect(page).to have_no_content "Received Invitations"
</pre>

===Functional Tests for sending an invitation by a team member===

Same as the first case, we let ‘student2064’ to pick up a topic and send an invitation to ‘student2065’. Then, ‘student2065’ accepts the invitation and becomes a team member. Now we test if ‘student2065’ can send an invitation to another student—‘student2066’.

<pre>
#invite another student
page.fill_in 'user_name', :with => 'student2066'
click_button('Invite')
expect(page).to have_content "Sent invitations"
expect(page).to have_content "student2066"
</pre>

Now, let’s create the third session and login as ‘student2066’. If the invitation sent by ‘student2065’ is successful, ‘student2066’ should be able to see an ‘Received Invitation’ by ‘student2065’ in ‘Your Team’ page.
<pre>
in_browser(:three) do
visit '/'
#login as student2065
user = User.find_by_name('student2066')
msg = user.to_yaml
File.open('log/diagnostic.txt', 'a') {|f| f.write msg }
visit root_path
fill_in 'login_name', with: 'student2066'
fill_in 'login_password', with: 'password'
click_button 'SIGN IN'

#test if a student can see an invitation
expect(page).to have_content "User: student2066"
expect(page).to have_content "TestTeam"
click_link "TestTeam"
expect(page).to have_content "Signup sheet"
expect(page).to have_content "Your team"
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "Received Invitations"
expect(page).to have_content "student2065"
#test if a student can accept an invitation
click_link "Accept"
expect(page).to have_content "Team Information"
expect(page).to have_content "Team members"
expect(page).to have_content "Edit name "
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
expect(page).to have_content "student2066"
expect(page).to have_content "Leave team"
end
</pre>

===Functional Tests for leaving a team by a team member===

Everything is same to the first case except the last two lines of codes. In the last two lines, we let ‘student2065’ to leave the team, if he really leaves, he will see “You no longer have a team” in the next page.

<pre>
click_link "Leave team"
expect(page).to have_content "You no longer have a team! "
</pre>

===Functional Tests for leaving a team by a team leader===

Everything is same to the first case before we change back to session one. If ‘student2064’ (Team leader) clicks “Leave team”, he should see “You no longer have a team” in the next page.
<pre>
in_browser(:one) do
click_link "Assignments"
click_link "TestTeam"
expect(page).to have_content "Your team"
click_link "Your team"
expect(page).to have_content "student2064"
expect(page).to have_content "student2065"
click_link "Leave team"
expect(page).to have_content "You no longer have a team! "
end
</pre>

=== Running the tests ===

The tests can be run on the terminal using the command:
<pre>
rspec specfile.rb
</pre>

Whether the test fails or succeeds, allows us to determine which parts of the system are functioning properly.

=== External Links ===
# link for forked repository
# Github link for original repository
# Github link for Capybara