Automated testing with Persona as the login tool -- ways of spoofing the login?

[harry.p...@gmail.com]

Hi all! I've been playing around with Persona as a login system, and I've managed to write some selenium tests that check that the user can log in and out with Persona, all my javascript works, etc etc.

Now that that's tested, I don't want my *other* selenium tests that need to be logged in to have to jump through all the persona hoops. I'd like some way of side-stepping that process, and just generating a browser session that's already logged in.

I can do this by manually creating sessions in the database and matching cookies in the selenium browser. *however*, I think that causes a disconnect between the Personal client-side state and the server-side state.

I'm using the Observer API, and I think what happens is that it gets told that `loggedInUser` is a certain email address that it doesn't recognise, so it immediately tries to log the user out.

Is there any way of getting around this? Some way of manually setting the Persona state to thinking it's already logged in? Or do I have to stop using the Observer API and switch over to the callback API? that feels like it would be a shame...

(Some background at http://www.obeythetestinggoat.com.)

[Lloyd Hilaiel]

Hey Harry,

There's a new api in town that might address your needs. You may choose to move to the "goldilocks" api, which is a simplification of .watch() / .request() that preserves all of the loved features of watch, while drastically reducing complexity, and removing the loggedInUser and onlogout events.

You can try this out now by using a small javascript shim that dan callahan wrote [1], and our goal is to implement this api in a backwards compatible way in the coming months.

very best,
lloyd

[1]: https://gist.github.com/callahad/6807882

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

[Harry Percival]

Thanks Lloyd!

Does that mean that the user can no longer remotely log out of all their sites? That seems like a shame. If there was some way of just injecting some state into navigator.id, that might be better? Maybe it's not such a big deal...

And I presume it means I would have to roll my own logout function, posting to /logout + reloading, or whatever it may be?

What do I get from the goldilocks API that I wouldn't get from .get?

[Lloyd Hilaiel]

On Oct 22, 2013, at 12:28 PM, Harry Percival <harry.p...@gmail.com> wrote:

> Thanks Lloyd!
>

> Does that mean that the user can no longer remotely log out of all their sites? That seems like a shame. If there was some way of just injecting some state into navigator.id, that might be better? Maybe it's not such a big deal…

It is a bit of a shame. The fact is though, we cannot implement remote logout at all for a significant percentage of users - given default cookie behaviors on iOS and other browsers.

However, when persona support is implemented native in UAs, we can re-introduce this feature in a much more robust way.

> And I presume it means I would have to roll my own logout function, posting to /logout + reloading, or whatever it may be?

It would mean simply that when a user clicks logout on your page, you clear their session and log them out.

> What do I get from the goldilocks API that I wouldn't get from .get?

Two things:
1. After first time email verification, a user is taken directly from the link in their email to your site in a logged in state.
2. For environments where the "redirect flow" is required (like web views on iOS, phone gap, etc), the user returns to your site logged in.

Both of these we believe are really important UX optimizations.

lloyd

[Mark Banner]

Hi,

On 22/10/2013 09:03, harry.p...@gmail.com wrote:
> Hi all! I've been playing around with Persona as a login system, and
I've managed to write some selenium tests that check that the user can
log in and out with Persona, all my javascript works, etc etc.
>
> Now that that's tested, I don't want my *other* selenium tests that
need to be logged in to have to jump through all the persona hoops. I'd
like some way of side-stepping that process, and just generating a
browser session that's already logged in.

On Talkilla, we actually use a shim instead of Persona. Instead of
loading the Persona include.js script for tests, we use a dummy file
that replaces the functionality. The advantage for us is that this does
not require any network access nor do we need to wait a long time for
logins to happen.

You can see what we did here:

https://github.com/mozilla/talkilla/pull/203/files

Mark.

[Jared Hirsch]

Hey Harry,

One option not discussed so far in this thread is using personatestuser.org to generate dummy accounts. It has a nice REST API, super easy to use. We use this in a lot of our tests (our tests are here[1]).

Assuming you can automate creating accounts on your own site, you could generate a persona test user, create an account on your backend, then run through the various flows.

Good luck, and feel free to share any blog posts or open-source code links that come out of your work with Persona :-)

Jared

[1] https://github.com/mozilla/browserid/tree/dev/automation-tests/tests

[Harry Percival]

Thanks Lloyd!

Does that mean that the user can no longer remotely log out of all their
sites? That seems like a shame. If there was some way of just injecting
some state into navigator.id, that might be better? Maybe it's not such a

big deal...

And I presume it means I would have to roll my own logout function, posting
to /logout + reloading, or whatever it may be?

What do I get from the goldilocks API that I wouldn't get from .get?

On 22 October 2013 09:09, Lloyd Hilaiel <ll...@mozilla.com> wrote:

> Hey Harry,
>
> There's a new api in town that might address your needs. You may choose
> to move to the "goldilocks" api, which is a simplification of .watch() /
> .request() that preserves all of the loved features of watch, while
> drastically reducing complexity, and removing the loggedInUser and onlogout
> events.
>
> You can try this out now by using a small javascript shim that dan
> callahan wrote [1], and our goal is to implement this api in a backwards
> compatible way in the coming months.
>
> very best,
> lloyd
>

> [1]: https://gist.github.com/**callahad/6807882<https://gist.github.com/callahad/6807882>

>
>
> On Oct 22, 2013, at 11:03 AM, harry.p...@gmail.com wrote:
>

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>
>
>

--
------------------------------
Harry J.W. Percival
------------------------------
Twitter: @hjwp
Mobile: +44 (0) 78877 02511
Skype: harry.percival

[Harry Percival]

Y'all asked about blog posts or open-source code that came out of my
persona investigations. If anyone's interested in testing, I have written
up some bits on testing persona, both client-side (with qunit and sinon.js)
and server-side (with Python. v. Django-specific) here:

http://chimera.labs.oreilly.com/books/1234000000754/ch14.html
http://chimera.labs.oreilly.com/books/1234000000754/ch15.html

source-code-wise, all the example code is on github:
https://github.com/hjwp/book-example/tree/chapter_13 (state at begin of
ch14)
https://github.com/hjwp/book-example/tree/chapter_14
https://github.com/hjwp/book-example/tree/chapter_15

They are chapters from a book I'm writing. Still in draft form, so
feedback and suggestions appreciated.

You'll see I've done a sort of pseudo-goldilocks approach of just using
watch with a do-nothing onlogout function which leaves me open to the
"logout doesn't work cos persona auto-logs-you-back-in" bugfeature, but I'm
currently glossing over that for now, planning to either use Dan's shim, or
wait til goldilocks becomes part of the released API.

cheers,
HP

http://www.obeythetestinggoat.com

On 22 October 2013 19:04, Jared Hirsch <6a...@mozilla.com> wrote:

> Hey Harry,
>
> One option not discussed so far in this thread is using
> personatestuser.org to generate dummy accounts. It has a nice REST API,
> super easy to use. We use this in a lot of our tests (our tests are
> here[1]).
>
> Assuming you can automate creating accounts on your own site, you could
> generate a persona test user, create an account on your backend, then run
> through the various flows.
>
> Good luck, and feel free to share any blog posts or open-source code links
> that come out of your work with Persona :-)
>
> Jared
>
> [1] https://github.com/mozilla/browserid/tree/dev/automation-tests/tests
>
> On Oct 22, 2013, at 1:03 AM, harry.p...@gmail.com wrote:
>

[Francois Marier]

Hi Harry,

Thanks for sending these links! It will be quite an interesting book.

I had a quick read through and I have three small comments:

1. We write the protocol name as "BrowserID", not "Browser-ID".

2. I wholeheartedly agree with your comments about how it's a bit weird
that Mozilla is still in the loop during verification. That's why we're
changing our recommendations and asking people to make use of
verification libraries instead of talking to verifier.login.persona.org
directly. That way, developers can "upgrade" to local verification
whenever it's ready without having to change any of their code.

In the case of Python, here's the library we recommend:

https://pypi.python.org/pypi/PyBrowserID

It has local and remote verification and currently defaults to remote
verification. I'm not sure how that fits the purpose of your coding
examples, but you may want to consider using that instead of POSTing to
the verifier.

3. I would recommend including the scheme in the audience you send to
the verifier. I'm surprised it works without, but relying on the
verifier to default to HTTP may not be a good idea. So I would suggest
"audience = 'http://localhost'" instead of just 'localhost'.

Francois