Need feedback for brand new Test::Mojo features

[s...@alexbyk.com]

Hello guys.
If you're using Mojolicious, you most likely test your app by
Test::Mojo. It works greates for testing cases when the visitor is a guest.

But if you're going to write a Facebook killer, you'll be missing a way
to test protected parts of your site because it's hard to calculate
cookies manually.


Please consider an example here
(https://gist.github.com/alexbyk/ad427b4aed2ebaba73a5)

Right now it's impossible (or very hard) to test what's going on because
routes are protected (we have to encrypt cookie manually and get somehow
a csrf_token)

Of course, You can do it something like this (a weird way):

# log in and find csrf_token in the html output
$t->get_ok('/')->post('/login', form => {pass => 'pass', login => 'login'});
my $csrf = $t->ua->get('/')->res->dom->at('#csrf')->text;

But that doesn't look like a right way.

It would be greate to have something like this:

$t->session(user => 'Cartman');
my $token = $t->csrf_token;

If you find those features useful and you miss them to, please vote for
them (thumbs up or '+1' appreciated) here. You can take a closer look
here https://github.com/kraih/mojo/pull/640 and if you can propose a
better way to do such things, pls let me know

[sri]

But if you're going to write a Facebook killer, you'll be missing a way
to test protected parts of your site because it's hard to calculate
cookies manually.

Which is why you don't create cookies manually, the client side is not supposed to touch them.

Right now it's impossible (or very hard) to test what's going on because
routes are protected (we have to encrypt cookie manually and get somehow
a csrf_token)

No, you are not supposed to do that, those are artifical test cases that have no relation to what your users see in the real world.

 

Of course, You can do it something like this (a weird way):

# log in and find csrf_token in the html output
$t->get_ok('/')->post('/login', form => {pass => 'pass', login => 'login'});
my $csrf = $t->ua->get('/')->res->dom->at('#csrf')->text;

But this is a realistic test, you are actually testing what your users are working with. Many applications specifically set the X-CSRF-Token header to make life easier for API clients.

--

sebastian

[sri]

Which is why you don't create cookies manually, the client side is not supposed to touch them.

To re-emphasize, the session cookie has the HttpOnly flag set, so in most browsers it is completely inaccessible.

    https://github.com/kraih/mojo/blob/master/lib/Mojolicious/Sessions.pm#L56

--

sebastian

[s...@alexbyk.com]

It is true for simple logging systems only.
For example, you can log in with a test user, but ... you need to know user's login and password.

In the real world if you can get a login and password (for example from the db), you do something wrong.
Of course, you can create a test user in the test. But it is true only for very simple authorization systems

In my case, users can log in using our FB clone (VK.com). So the only way to test what's going on with registered users is to set a session and bypass authorization (or login via my real VK account, but it's too hard)
Or if users have to confirm an email, phone and so on... $t->get->find('#id') won't work for that cases.

The second item against weird realistic test is that it becomes broken every time when templates are changed.

And you still need to take a csrf_token somehow.

My example methods works just as they should. (the same way if the session was created in the application)

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious...@googlegroups.com.
To post to this group, send email to mojol...@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[s...@alexbyk.com]

In my example, session method doesn't try to manipulate sessions. It allow set it once (do login action) and forget about sessions at all.
It is necessary for cases when you can not get log/pass values or cannot just login like an empty user.

So it'll keep the test clean

[sri]

FYI: There is actually a pull request for this stuff and Alex is trying to find out if there is broader interest in having this functionality in Mojolicious core, instead of in a separate CPAN distribution. At the moment i believe it should stay separate, but will keep an eye on the discussion.

    https://github.com/kraih/mojo/pull/640

--

sebastian