chrismo
911a52ee83
This isn't the cleanest approach, but should be good for now. Obviously, there are two contexts for these specs: one is from the maintainer's standpoint, the other is from the trainee who is using RailsGoat for training. The maintainer wants all of these specs to pass, to ensure the vulnerabilities are still functional as vulnerabilities. The trainee could potentially use these specs (though reading the specs contains spoilers) to track and verify their fixes. I've wired in a pending block around each assertion that checks a method to see what the result of the pending call would be. You can see examples of how this works with conditions here: https://www.relishapp.com/rspec/rspec-core/v/2-14/docs/pending/pending-examples This means these specs will all fail now by default (the trainee context), but will pass, when vulnerable, if the RAILSGOAT_MAINTAINER env var is set. The only flaw at the moment is that in the trainee context, fixing the vulnerabilities will result in the specs going from failing to _pending_, not passing (which makes sense, given how we're using RSpec's pending functionality). Maybe it'd be simpler/better to have a boolean toggle of our own somehow wrap the assertions in blocks to do explicitly what we want (flip-flop the result based on the context).
20 lines
638 B
Ruby
20 lines
638 B
Ruby
# By default this will return true, and thus all of the Capybara specs will
|
|
# fail until a developer using the site for training has patched up all of
|
|
# the vulnerabilities.
|
|
#
|
|
# However, RailsGoat maintainers need the Capybara features to pass to indicate
|
|
# changes to the site have not inadvertently removed or fixed any vulnerabilities
|
|
# since the whole point is to provide a site for a developer to fix.
|
|
def verifying_fixed?
|
|
!ENV['RAILSGOAT_MAINTAINER']
|
|
end
|
|
|
|
def login(user)
|
|
visit '/'
|
|
within('.signup') do
|
|
fill_in 'email', :with => user.email
|
|
fill_in 'password', :with => user.clear_password
|
|
end
|
|
click_on 'Login'
|
|
end
|