Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[signin] Realms ready for testing
37 views
Skip to first unread message
Sean McArthur
Sep 3, 2013, 11:52:59 PM9/3/13
to dev-id...@lists.mozilla.org, jb...@mozillafoundation.org, Luke Crouch
The Realms work is ready for review and testing. Hopefully it works exactly
as was specified. https://github.com/mozilla/browserid/pull/3854
If you just want to play with it RIGHT NAOW, I set up an example RP that is
using the awsbox I've deployed:
http://static.seanmonstar.com/persona/realms.html
After logging into 1, hitting the link to the other page in the realm (the
subdomain is different) should get you automatically logged into it.
jbuck, lcrouch, etc - Those who want to test it against their own sites can
use it at https://realms.personatest.org. Simply use that domain wherever
you normally use login.persona.org, including the verifier.
Shane, Jared, etc - Besides general review, I had some confusion on when
`email` should be set or removed vs `logged_in` in site storage. I tried to
include tests for each state the user could be in. There is also a B2G
issue that needs some eyeballs/explaining.
Jed, Ozten, etc - I altered a test for `BrowserID.internal.get`, since I
wanted it to use the same code path everything else was using, which is
User.getSilentAssertion(). However, doing that, I broke said test. I
couldn't understand what that test was testing, so that needs some help.
There's a comment at the test explaining my WTF.
There's still a legal bug open regarding unified TOS/PP. I can't imagine a
problem, but it's still there. Jishnu wants more context from myself and
Lloyd.
Want more backstory on realms? Read!
https://groups.google.com/forum/#!topic/mozilla.dev.identity/z3d_wj6Jjq0/discussion
as was specified. https://github.com/mozilla/browserid/pull/3854
If you just want to play with it RIGHT NAOW, I set up an example RP that is
using the awsbox I've deployed:
http://static.seanmonstar.com/persona/realms.html
After logging into 1, hitting the link to the other page in the realm (the
subdomain is different) should get you automatically logged into it.
jbuck, lcrouch, etc - Those who want to test it against their own sites can
use it at https://realms.personatest.org. Simply use that domain wherever
you normally use login.persona.org, including the verifier.
Shane, Jared, etc - Besides general review, I had some confusion on when
`email` should be set or removed vs `logged_in` in site storage. I tried to
include tests for each state the user could be in. There is also a B2G
issue that needs some eyeballs/explaining.
Jed, Ozten, etc - I altered a test for `BrowserID.internal.get`, since I
wanted it to use the same code path everything else was using, which is
User.getSilentAssertion(). However, doing that, I broke said test. I
couldn't understand what that test was testing, so that needs some help.
There's a comment at the test explaining my WTF.
There's still a legal bug open regarding unified TOS/PP. I can't imagine a
problem, but it's still there. Jishnu wants more context from myself and
Lloyd.
Want more backstory on realms? Read!
https://groups.google.com/forum/#!topic/mozilla.dev.identity/z3d_wj6Jjq0/discussion
Shane Tomlinson
Sep 4, 2013, 3:51:36 AM9/4/13
to dev-id...@lists.mozilla.org, Simon Wex
HOT!
On 04/09/2013 04:52, Sean McArthur wrote:
> The Realms work is ready for review and testing. Hopefully it works exactly
> as was specified. https://github.com/mozilla/browserid/pull/3854
>
A quick and dirty explanation:
email is used to store the site->email association.
logged_in is a boolean flag used to indicate whether a "silent"
assertion can be generated for a site.
If email is set, and logged_in is set to true, an assertion can be
automatically generated when calling navigator.id.watch.
If email is set, and logged_in is set to false, no silent assertions are
generated for .watch, BUT when the user opens the dialog, the email will
be pre-selected.
If email is not set, logged_in is ignored.
>
> Jed, Ozten, etc - I altered a test for `BrowserID.internal.get`, since I
> wanted it to use the same code path everything else was using, which is
> User.getSilentAssertion(). However, doing that, I broke said test. I
> couldn't understand what that test was testing, so that needs some help.
> There's a comment at the test explaining my WTF.
I may have added these tests. Will look.
Shane
On 04/09/2013 04:52, Sean McArthur wrote:
> The Realms work is ready for review and testing. Hopefully it works exactly
> as was specified. https://github.com/mozilla/browserid/pull/3854
>
> Shane, Jared, etc - Besides general review, I had some confusion on when
> `email` should be set or removed vs `logged_in` in site storage. I tried to
> include tests for each state the user could be in. There is also a B2G
> issue that needs some eyeballs/explaining.
This points to the need to update the front end development wiki.
> `email` should be set or removed vs `logged_in` in site storage. I tried to
> include tests for each state the user could be in. There is also a B2G
> issue that needs some eyeballs/explaining.
A quick and dirty explanation:
email is used to store the site->email association.
logged_in is a boolean flag used to indicate whether a "silent"
assertion can be generated for a site.
If email is set, and logged_in is set to true, an assertion can be
automatically generated when calling navigator.id.watch.
If email is set, and logged_in is set to false, no silent assertions are
generated for .watch, BUT when the user opens the dialog, the email will
be pre-selected.
If email is not set, logged_in is ignored.
>
> Jed, Ozten, etc - I altered a test for `BrowserID.internal.get`, since I
> wanted it to use the same code path everything else was using, which is
> User.getSilentAssertion(). However, doing that, I broke said test. I
> couldn't understand what that test was testing, so that needs some help.
> There's a comment at the test explaining my WTF.
Shane
Shane Tomlinson
Sep 4, 2013, 5:14:31 AM9/4/13
to dev-id...@lists.mozilla.org
On 04/09/2013 05:52, Sean McArthur wrote:
>
> Shane, Jared, etc - Besides general review, I had some confusion on when
> `email` should be set or removed vs `logged_in` in site storage. I tried to
> include tests for each state the user could be in. There is also a B2G
> issue that needs some eyeballs/explaining.
The wiki is updated:
>
> Shane, Jared, etc - Besides general review, I had some confusion on when
> `email` should be set or removed vs `logged_in` in site storage. I tried to
> include tests for each state the user could be in. There is also a B2G
> issue that needs some eyeballs/explaining.
https://github.com/mozilla/browserid/wiki/Front-End-Development#persisting-data-on-the-client
Shane
Sean McArthur
Sep 9, 2013, 1:49:35 PM9/9/13
to Sean McArthur, Jedediah Parsons, jb...@mozillafoundation.org, Luke Crouch, dev-id...@lists.mozilla.org
After some discussion on the pull request, it was highly suggested that we
require HTTPS for the browserid-realm file. This does not mean every site
that is part of the realm needs to be served over HTTPS, only the
.well-known file. Since we require HTTPS, that means we can drop the scheme
from the `realm` property in the watch() function.
navigator.id.watch({
realm: 'foo.com'
});
Since the individual sites can still be HTTP or HTTPS, the scheme is still
required in the array in the browserid-realm file.
Other notes:
Security review of the Realms features is schedule for tomorrow, Sept 10th.
Also, still need feedback or support from Native team to make sure this
works with FirefoxOS.
On Tue, Sep 3, 2013 at 8:52 PM, Sean McArthur <smca...@mozilla.com> wrote:
> The Realms work is ready for review and testing. Hopefully it works
> exactly as was specified. https://github.com/mozilla/browserid/pull/3854
>
require HTTPS for the browserid-realm file. This does not mean every site
that is part of the realm needs to be served over HTTPS, only the
.well-known file. Since we require HTTPS, that means we can drop the scheme
from the `realm` property in the watch() function.
navigator.id.watch({
realm: 'foo.com'
});
Since the individual sites can still be HTTP or HTTPS, the scheme is still
required in the array in the browserid-realm file.
Other notes:
Security review of the Realms features is schedule for tomorrow, Sept 10th.
Also, still need feedback or support from Native team to make sure this
works with FirefoxOS.
On Tue, Sep 3, 2013 at 8:52 PM, Sean McArthur <smca...@mozilla.com> wrote:
> The Realms work is ready for review and testing. Hopefully it works
> exactly as was specified. https://github.com/mozilla/browserid/pull/3854
>
> If you just want to play with it RIGHT NAOW, I set up an example RP that
> is using the awsbox I've deployed:
> http://static.seanmonstar.com/persona/realms.html
> After logging into 1, hitting the link to the other page in the realm (the
> subdomain is different) should get you automatically logged into it.
>
>
> jbuck, lcrouch, etc - Those who want to test it against their own sites
> can use it at https://realms.personatest.org. Simply use that domain
> wherever you normally use login.persona.org, including the verifier.
>
> is using the awsbox I've deployed:
> http://static.seanmonstar.com/persona/realms.html
> After logging into 1, hitting the link to the other page in the realm (the
> subdomain is different) should get you automatically logged into it.
>
>
> jbuck, lcrouch, etc - Those who want to test it against their own sites
> can use it at https://realms.personatest.org. Simply use that domain
> wherever you normally use login.persona.org, including the verifier.
>
> Shane, Jared, etc - Besides general review, I had some confusion on when
> `email` should be set or removed vs `logged_in` in site storage. I tried to
> include tests for each state the user could be in. There is also a B2G
> issue that needs some eyeballs/explaining.
>
> `email` should be set or removed vs `logged_in` in site storage. I tried to
> include tests for each state the user could be in. There is also a B2G
> issue that needs some eyeballs/explaining.
>
> Jed, Ozten, etc - I altered a test for `BrowserID.internal.get`, since I
> wanted it to use the same code path everything else was using, which is
> User.getSilentAssertion(). However, doing that, I broke said test. I
> couldn't understand what that test was testing, so that needs some help.
> There's a comment at the test explaining my WTF.
>
> wanted it to use the same code path everything else was using, which is
> User.getSilentAssertion(). However, doing that, I broke said test. I
> couldn't understand what that test was testing, so that needs some help.
> There's a comment at the test explaining my WTF.
>
Luke Crouch
Sep 9, 2013, 3:09:05 PM9/9/13
to Sean McArthur, jb...@mozillafoundation.org, Jedediah Parsons, dev-id...@lists.mozilla.org
Thanks for the update. That should work for us - we're going to put or
realm file on MDN which is https already.
-L
On 9/9/13 12:49 PM, Sean McArthur wrote:
> After some discussion on the pull request, it was highly suggested
> that we require HTTPS for the browserid-realm file. This does not mean
> every site that is part of the realm needs to be served over HTTPS,
> only the .well-known file. Since we require HTTPS, that means we can
> drop the scheme from the `realm` property in the watch() function.
>
> navigator.id.watch({
> realm: 'foo.com <http://foo.com>'
>
>
realm file on MDN which is https already.
-L
On 9/9/13 12:49 PM, Sean McArthur wrote:
> After some discussion on the pull request, it was highly suggested
> that we require HTTPS for the browserid-realm file. This does not mean
> every site that is part of the realm needs to be served over HTTPS,
> only the .well-known file. Since we require HTTPS, that means we can
> drop the scheme from the `realm` property in the watch() function.
>
> navigator.id.watch({
> });
>
> Since the individual sites can still be HTTP or HTTPS, the scheme is
> still required in the array in the browserid-realm file.
>
> Other notes:
>
> Security review of the Realms features is schedule for tomorrow, Sept
> 10th.
>
> Also, still need feedback or support from Native team to make sure
> this works with FirefoxOS.
>
>
> On Tue, Sep 3, 2013 at 8:52 PM, Sean McArthur <smca...@mozilla.com
> <mailto:smca...@mozilla.com>> wrote:
>
> The Realms work is ready for review and testing. Hopefully it
> works exactly as was specified.
> https://github.com/mozilla/browserid/pull/3854
>
> If you just want to play with it RIGHT NAOW, I set up an example
> RP that is using the awsbox I've deployed:
> http://static.seanmonstar.com/persona/realms.html
> After logging into 1, hitting the link to the other page in the
> realm (the subdomain is different) should get you automatically
> logged into it.
>
>
> jbuck, lcrouch, etc - Those who want to test it against their own
> sites can use it at https://realms.personatest.org. Simply use
> that domain wherever you normally use login.persona.org
> <http://login.persona.org>, including the verifier.
>
> Since the individual sites can still be HTTP or HTTPS, the scheme is
> still required in the array in the browserid-realm file.
>
> Other notes:
>
> Security review of the Realms features is schedule for tomorrow, Sept
> 10th.
>
> Also, still need feedback or support from Native team to make sure
> this works with FirefoxOS.
>
>
> On Tue, Sep 3, 2013 at 8:52 PM, Sean McArthur <smca...@mozilla.com
> <mailto:smca...@mozilla.com>> wrote:
>
> The Realms work is ready for review and testing. Hopefully it
> works exactly as was specified.
> https://github.com/mozilla/browserid/pull/3854
>
> If you just want to play with it RIGHT NAOW, I set up an example
> RP that is using the awsbox I've deployed:
> http://static.seanmonstar.com/persona/realms.html
> After logging into 1, hitting the link to the other page in the
> realm (the subdomain is different) should get you automatically
> logged into it.
>
>
> jbuck, lcrouch, etc - Those who want to test it against their own
> sites can use it at https://realms.personatest.org. Simply use
> that domain wherever you normally use login.persona.org
>
> Shane, Jared, etc - Besides general review, I had some confusion
> on when `email` should be set or removed vs `logged_in` in site
> storage. I tried to include tests for each state the user could be
> in. There is also a B2G issue that needs some eyeballs/explaining.
>
> Jed, Ozten, etc - I altered a test for `BrowserID.internal.get`,
> since I wanted it to use the same code path everything else was
> using, which is User.getSilentAssertion(). However, doing that, I
> broke said test. I couldn't understand what that test was testing,
> so that needs some help. There's a comment at the test explaining
> my WTF.
>
> There's still a legal bug open regarding unified TOS/PP. I can't
> imagine a problem, but it's still there. Jishnu wants more context
> from myself and Lloyd.
>
> Want more backstory on realms? Read!
> https://groups.google.com/forum/#!topic/mozilla.dev.identity/z3d_wj6Jjq0/discussion
> <https://groups.google.com/forum/#%21topic/mozilla.dev.identity/z3d_wj6Jjq0/discussion>
> Shane, Jared, etc - Besides general review, I had some confusion
> on when `email` should be set or removed vs `logged_in` in site
> storage. I tried to include tests for each state the user could be
> in. There is also a B2G issue that needs some eyeballs/explaining.
>
> Jed, Ozten, etc - I altered a test for `BrowserID.internal.get`,
> since I wanted it to use the same code path everything else was
> using, which is User.getSilentAssertion(). However, doing that, I
> broke said test. I couldn't understand what that test was testing,
> so that needs some help. There's a comment at the test explaining
> my WTF.
>
> There's still a legal bug open regarding unified TOS/PP. I can't
> imagine a problem, but it's still there. Jishnu wants more context
> from myself and Lloyd.
>
> Want more backstory on realms? Read!
> https://groups.google.com/forum/#!topic/mozilla.dev.identity/z3d_wj6Jjq0/discussion
>
>
Edwin Wong
Sep 9, 2013, 4:57:13 PM9/9/13
to Sean McArthur, dev-id...@lists.mozilla.org
Sean, I'll talk with the QA team about getting some manual/automated tests cycles on this.
-edwin
On Sep 3, 2013, at 8:52 PM, Sean McArthur <smca...@mozilla.com> wrote:
> The Realms work is ready for review and testing. Hopefully it works exactly
> as was specified. https://github.com/mozilla/browserid/pull/3854
>
> If you just want to play with it RIGHT NAOW, I set up an example RP that is
> using the awsbox I've deployed:
> http://static.seanmonstar.com/persona/realms.html
> After logging into 1, hitting the link to the other page in the realm (the
> subdomain is different) should get you automatically logged into it.
>
>
> jbuck, lcrouch, etc - Those who want to test it against their own sites can
> use it at https://realms.personatest.org. Simply use that domain wherever
> you normally use login.persona.org, including the verifier.
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
-edwin
On Sep 3, 2013, at 8:52 PM, Sean McArthur <smca...@mozilla.com> wrote:
> The Realms work is ready for review and testing. Hopefully it works exactly
> as was specified. https://github.com/mozilla/browserid/pull/3854
>
> If you just want to play with it RIGHT NAOW, I set up an example RP that is
> using the awsbox I've deployed:
> http://static.seanmonstar.com/persona/realms.html
> After logging into 1, hitting the link to the other page in the realm (the
> subdomain is different) should get you automatically logged into it.
>
>
> jbuck, lcrouch, etc - Those who want to test it against their own sites can
> use it at https://realms.personatest.org. Simply use that domain wherever
>
> Shane, Jared, etc - Besides general review, I had some confusion on when
> `email` should be set or removed vs `logged_in` in site storage. I tried to
> include tests for each state the user could be in. There is also a B2G
> issue that needs some eyeballs/explaining.
>
> Jed, Ozten, etc - I altered a test for `BrowserID.internal.get`, since I
> wanted it to use the same code path everything else was using, which is
> User.getSilentAssertion(). However, doing that, I broke said test. I
> couldn't understand what that test was testing, so that needs some help.
> There's a comment at the test explaining my WTF.
>
> There's still a legal bug open regarding unified TOS/PP. I can't imagine a
> problem, but it's still there. Jishnu wants more context from myself and
> Lloyd.
>
> Want more backstory on realms? Read!
> https://groups.google.com/forum/#!topic/mozilla.dev.identity/z3d_wj6Jjq0/discussion
> _______________________________________________
> Shane, Jared, etc - Besides general review, I had some confusion on when
> `email` should be set or removed vs `logged_in` in site storage. I tried to
> include tests for each state the user could be in. There is also a B2G
> issue that needs some eyeballs/explaining.
>
> Jed, Ozten, etc - I altered a test for `BrowserID.internal.get`, since I
> wanted it to use the same code path everything else was using, which is
> User.getSilentAssertion(). However, doing that, I broke said test. I
> couldn't understand what that test was testing, so that needs some help.
> There's a comment at the test explaining my WTF.
>
> There's still a legal bug open regarding unified TOS/PP. I can't imagine a
> problem, but it's still there. Jishnu wants more context from myself and
> Lloyd.
>
> Want more backstory on realms? Read!
> https://groups.google.com/forum/#!topic/mozilla.dev.identity/z3d_wj6Jjq0/discussion
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
0 new messages