Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Jerry Vonau-2
Great piece of deductive testing Anna, way to go. Forwarding for further investigation.

Jerry

---------- Forwarded message ----------
From: Anna <[hidden email]>
Date: 5 August 2013 15:02
Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable
To: xsce-devel <[hidden email]>


I just realized that someone will probably ask what's the most recent build where Moodle transparent auth did work.  Lucky for me, I just had to test one older.  Moodle transparent auth DOES work in 13.2.0-12.

So whatever broke client side Moodle transparent auth should be confined to 13.2.0-13.


On Mon, Aug 5, 2013 at 2:19 PM, Anna <[hidden email]> wrote:
I very recently upgraded my little herd of XOs to the latest stable build 13.2.0-13.  Unfortunately, something in that build has broken Moodle's transparent authentication.  When a registered client goes to http://schoolserver/moodle, all it gets is the login page.

Now, that's not unheard of, you can usually just click the "Home" button and get automatically logged in.  But when I've seen that before, the XO's SN is filled out in the Username field on the login page.  The 13.2.0-13 XO doesn't show that.  No matter what you click on in the Moodle login page, it never logs in.

To verify it was a client side issue, I flashed an XO-1 with 13.1.0 stable, and registered first to be admin.  I also registered a 13.2.0-13 as the second client.  On the 13.1.0, I can go to the Moodle homepage and it automatically logged me in.  I tried again to access the Moodle homepage on the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin XO, I went to Site Administration -> Users -> Accounts -> Browse list of users and saw both XOs listed.  It indicated that the 13.2.0-13 client had never logged in.

So, the user account is being created on the server for the 13.2.0-13 XO upon registration, but client side transparent authentication is not working.

To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I went to http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pl and the test was successful.

Now, I have successfully tested Moodle transparent auth with previous iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that broke transparent auth must have been relatively recent.

I took a look at the Browse Activity version between the two clients:
13.1.0 = Browse 149
13.2.0-13 = Browse 149.3

I knew it wouldn't make a difference, but I also tested the 13.2.0-13 as first registration and it doesn't care that its the admin user.  And also tested with a fresh flash to make sure there wasn't something sticky in there from a previous registration gumming things up.

I've tested this with the XSCE installed a couple days ago (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I also remembered I have an XS 0.6 (duh, Anna) and the results were the same.  I don't have an XS 0.7 installation, but I would expect the same results.

Since this is a client side issue, I'm not sure where to go from here as far as troubleshooting.

Anna 



_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Gonzalo Odiard-3
There are a ticket filled?

Gonzalo


On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau <[hidden email]> wrote:
Great piece of deductive testing Anna, way to go. Forwarding for further investigation.

Jerry

---------- Forwarded message ----------
From: Anna <[hidden email]>
Date: 5 August 2013 15:02
Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable
To: xsce-devel <[hidden email]>


I just realized that someone will probably ask what's the most recent build where Moodle transparent auth did work.  Lucky for me, I just had to test one older.  Moodle transparent auth DOES work in 13.2.0-12.

So whatever broke client side Moodle transparent auth should be confined to 13.2.0-13.


On Mon, Aug 5, 2013 at 2:19 PM, Anna <[hidden email]> wrote:
I very recently upgraded my little herd of XOs to the latest stable build 13.2.0-13.  Unfortunately, something in that build has broken Moodle's transparent authentication.  When a registered client goes to http://schoolserver/moodle, all it gets is the login page.

Now, that's not unheard of, you can usually just click the "Home" button and get automatically logged in.  But when I've seen that before, the XO's SN is filled out in the Username field on the login page.  The 13.2.0-13 XO doesn't show that.  No matter what you click on in the Moodle login page, it never logs in.

To verify it was a client side issue, I flashed an XO-1 with 13.1.0 stable, and registered first to be admin.  I also registered a 13.2.0-13 as the second client.  On the 13.1.0, I can go to the Moodle homepage and it automatically logged me in.  I tried again to access the Moodle homepage on the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin XO, I went to Site Administration -> Users -> Accounts -> Browse list of users and saw both XOs listed.  It indicated that the 13.2.0-13 client had never logged in.

So, the user account is being created on the server for the 13.2.0-13 XO upon registration, but client side transparent authentication is not working.

To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I went to http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pl and the test was successful.

Now, I have successfully tested Moodle transparent auth with previous iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that broke transparent auth must have been relatively recent.

I took a look at the Browse Activity version between the two clients:
13.1.0 = Browse 149
13.2.0-13 = Browse 149.3

I knew it wouldn't make a difference, but I also tested the 13.2.0-13 as first registration and it doesn't care that its the admin user.  And also tested with a fresh flash to make sure there wasn't something sticky in there from a previous registration gumming things up.

I've tested this with the XSCE installed a couple days ago (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I also remembered I have an XS 0.6 (duh, Anna) and the results were the same.  I don't have an XS 0.7 installation, but I would expect the same results.

Since this is a client side issue, I'm not sure where to go from here as far as troubleshooting.

Anna 



_______________________________________________
Sugar-devel mailing list
[hidden email]
http://lists.sugarlabs.org/listinfo/sugar-devel



_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Jerry Vonau-2
Think it's more of a question of looking for confirmation. Is anybody else seeing this behavior on 13.2.0-13 on XO-1s when used with any version of school-servers? I'm at a loss trying to explain why this is occurring to Anna. With the noted behavior where would you file the bug report? OLPC is what I'm thinking but looking if someone else might be impacted also or can confirm this.

Jerry

On 6 August 2013 05:12, Gonzalo Odiard <[hidden email]> wrote:
There are a ticket filled?

Gonzalo


On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau <[hidden email]> wrote:
Great piece of deductive testing Anna, way to go. Forwarding for further investigation.

Jerry

---------- Forwarded message ----------
From: Anna <[hidden email]>
Date: 5 August 2013 15:02
Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable
To: xsce-devel <[hidden email]>


I just realized that someone will probably ask what's the most recent build where Moodle transparent auth did work.  Lucky for me, I just had to test one older.  Moodle transparent auth DOES work in 13.2.0-12.

So whatever broke client side Moodle transparent auth should be confined to 13.2.0-13.


On Mon, Aug 5, 2013 at 2:19 PM, Anna <[hidden email]> wrote:
I very recently upgraded my little herd of XOs to the latest stable build 13.2.0-13.  Unfortunately, something in that build has broken Moodle's transparent authentication.  When a registered client goes to http://schoolserver/moodle, all it gets is the login page.

Now, that's not unheard of, you can usually just click the "Home" button and get automatically logged in.  But when I've seen that before, the XO's SN is filled out in the Username field on the login page.  The 13.2.0-13 XO doesn't show that.  No matter what you click on in the Moodle login page, it never logs in.

To verify it was a client side issue, I flashed an XO-1 with 13.1.0 stable, and registered first to be admin.  I also registered a 13.2.0-13 as the second client.  On the 13.1.0, I can go to the Moodle homepage and it automatically logged me in.  I tried again to access the Moodle homepage on the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin XO, I went to Site Administration -> Users -> Accounts -> Browse list of users and saw both XOs listed.  It indicated that the 13.2.0-13 client had never logged in.

So, the user account is being created on the server for the 13.2.0-13 XO upon registration, but client side transparent authentication is not working.

To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I went to http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pl and the test was successful.

Now, I have successfully tested Moodle transparent auth with previous iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that broke transparent auth must have been relatively recent.

I took a look at the Browse Activity version between the two clients:
13.1.0 = Browse 149
13.2.0-13 = Browse 149.3

I knew it wouldn't make a difference, but I also tested the 13.2.0-13 as first registration and it doesn't care that its the admin user.  And also tested with a fresh flash to make sure there wasn't something sticky in there from a previous registration gumming things up.

I've tested this with the XSCE installed a couple days ago (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I also remembered I have an XS 0.6 (duh, Anna) and the results were the same.  I don't have an XS 0.7 installation, but I would expect the same results.

Since this is a client side issue, I'm not sure where to go from here as far as troubleshooting.

Anna 



_______________________________________________
Sugar-devel mailing list
[hidden email]
http://lists.sugarlabs.org/listinfo/sugar-devel




_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Gonzalo Odiard-3
I don't have a school server to try.
You should fill a ticket on bugs.sugarlabs.org
cced: Manuel Quiñones, who maintain Browse activity.

Gonzalo


On Tue, Aug 6, 2013 at 12:08 PM, Jerry Vonau <[hidden email]> wrote:
Think it's more of a question of looking for confirmation. Is anybody else seeing this behavior on 13.2.0-13 on XO-1s when used with any version of school-servers? I'm at a loss trying to explain why this is occurring to Anna. With the noted behavior where would you file the bug report? OLPC is what I'm thinking but looking if someone else might be impacted also or can confirm this.

Jerry


On 6 August 2013 05:12, Gonzalo Odiard <[hidden email]> wrote:
There are a ticket filled?

Gonzalo


On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau <[hidden email]> wrote:
Great piece of deductive testing Anna, way to go. Forwarding for further investigation.

Jerry

---------- Forwarded message ----------
From: Anna <[hidden email]>
Date: 5 August 2013 15:02
Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable
To: xsce-devel <[hidden email]>


I just realized that someone will probably ask what's the most recent build where Moodle transparent auth did work.  Lucky for me, I just had to test one older.  Moodle transparent auth DOES work in 13.2.0-12.

So whatever broke client side Moodle transparent auth should be confined to 13.2.0-13.


On Mon, Aug 5, 2013 at 2:19 PM, Anna <[hidden email]> wrote:
I very recently upgraded my little herd of XOs to the latest stable build 13.2.0-13.  Unfortunately, something in that build has broken Moodle's transparent authentication.  When a registered client goes to http://schoolserver/moodle, all it gets is the login page.

Now, that's not unheard of, you can usually just click the "Home" button and get automatically logged in.  But when I've seen that before, the XO's SN is filled out in the Username field on the login page.  The 13.2.0-13 XO doesn't show that.  No matter what you click on in the Moodle login page, it never logs in.

To verify it was a client side issue, I flashed an XO-1 with 13.1.0 stable, and registered first to be admin.  I also registered a 13.2.0-13 as the second client.  On the 13.1.0, I can go to the Moodle homepage and it automatically logged me in.  I tried again to access the Moodle homepage on the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin XO, I went to Site Administration -> Users -> Accounts -> Browse list of users and saw both XOs listed.  It indicated that the 13.2.0-13 client had never logged in.

So, the user account is being created on the server for the 13.2.0-13 XO upon registration, but client side transparent authentication is not working.

To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I went to http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pl and the test was successful.

Now, I have successfully tested Moodle transparent auth with previous iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that broke transparent auth must have been relatively recent.

I took a look at the Browse Activity version between the two clients:
13.1.0 = Browse 149
13.2.0-13 = Browse 149.3

I knew it wouldn't make a difference, but I also tested the 13.2.0-13 as first registration and it doesn't care that its the admin user.  And also tested with a fresh flash to make sure there wasn't something sticky in there from a previous registration gumming things up.

I've tested this with the XSCE installed a couple days ago (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I also remembered I have an XS 0.6 (duh, Anna) and the results were the same.  I don't have an XS 0.7 installation, but I would expect the same results.

Since this is a client side issue, I'm not sure where to go from here as far as troubleshooting.

Anna 



_______________________________________________
Sugar-devel mailing list
[hidden email]
http://lists.sugarlabs.org/listinfo/sugar-devel





_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Samuel Greenfeld
I reimaged & registered a XO-1.75 and a XO-4 with 13.2.0 to a XS-0.7 schoolserver.  Afterwards I opened Browse, and was able to open http://schoolserver/ to login to Moodle without problems.

This does not mean that there is not a bug with 13.2.0, XS, and/or XSCE; but one thing you could try is to fully stop and restart the Browse activity after registering if the first login attempt does not work.  Sometimes I have found this helps.


On Tue, Aug 6, 2013 at 11:14 AM, Gonzalo Odiard <[hidden email]> wrote:
I don't have a school server to try.
You should fill a ticket on bugs.sugarlabs.org
cced: Manuel Quiñones, who maintain Browse activity.

Gonzalo


On Tue, Aug 6, 2013 at 12:08 PM, Jerry Vonau <[hidden email]> wrote:
Think it's more of a question of looking for confirmation. Is anybody else seeing this behavior on 13.2.0-13 on XO-1s when used with any version of school-servers? I'm at a loss trying to explain why this is occurring to Anna. With the noted behavior where would you file the bug report? OLPC is what I'm thinking but looking if someone else might be impacted also or can confirm this.

Jerry


On 6 August 2013 05:12, Gonzalo Odiard <[hidden email]> wrote:
There are a ticket filled?

Gonzalo


On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau <[hidden email]> wrote:
Great piece of deductive testing Anna, way to go. Forwarding for further investigation.

Jerry

---------- Forwarded message ----------
From: Anna <[hidden email]>
Date: 5 August 2013 15:02
Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable
To: xsce-devel <[hidden email]>


I just realized that someone will probably ask what's the most recent build where Moodle transparent auth did work.  Lucky for me, I just had to test one older.  Moodle transparent auth DOES work in 13.2.0-12.

So whatever broke client side Moodle transparent auth should be confined to 13.2.0-13.


On Mon, Aug 5, 2013 at 2:19 PM, Anna <[hidden email]> wrote:
I very recently upgraded my little herd of XOs to the latest stable build 13.2.0-13.  Unfortunately, something in that build has broken Moodle's transparent authentication.  When a registered client goes to http://schoolserver/moodle, all it gets is the login page.

Now, that's not unheard of, you can usually just click the "Home" button and get automatically logged in.  But when I've seen that before, the XO's SN is filled out in the Username field on the login page.  The 13.2.0-13 XO doesn't show that.  No matter what you click on in the Moodle login page, it never logs in.

To verify it was a client side issue, I flashed an XO-1 with 13.1.0 stable, and registered first to be admin.  I also registered a 13.2.0-13 as the second client.  On the 13.1.0, I can go to the Moodle homepage and it automatically logged me in.  I tried again to access the Moodle homepage on the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin XO, I went to Site Administration -> Users -> Accounts -> Browse list of users and saw both XOs listed.  It indicated that the 13.2.0-13 client had never logged in.

So, the user account is being created on the server for the 13.2.0-13 XO upon registration, but client side transparent authentication is not working.

To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I went to http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pl and the test was successful.

Now, I have successfully tested Moodle transparent auth with previous iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that broke transparent auth must have been relatively recent.

I took a look at the Browse Activity version between the two clients:
13.1.0 = Browse 149
13.2.0-13 = Browse 149.3

I knew it wouldn't make a difference, but I also tested the 13.2.0-13 as first registration and it doesn't care that its the admin user.  And also tested with a fresh flash to make sure there wasn't something sticky in there from a previous registration gumming things up.

I've tested this with the XSCE installed a couple days ago (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I also remembered I have an XS 0.6 (duh, Anna) and the results were the same.  I don't have an XS 0.7 installation, but I would expect the same results.

Since this is a client side issue, I'm not sure where to go from here as far as troubleshooting.

Anna 



_______________________________________________
Sugar-devel mailing list
[hidden email]
http://lists.sugarlabs.org/listinfo/sugar-devel





_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel



_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Jerry Vonau-2
This behavior was noted with XO-1s only, all others(1.5,1.75,4) appear work fine in testing.

Jerry

 

On 6 August 2013 13:09, Samuel Greenfeld <[hidden email]> wrote:
I reimaged & registered a XO-1.75 and a XO-4 with 13.2.0 to a XS-0.7 schoolserver.  Afterwards I opened Browse, and was able to open http://schoolserver/ to login to Moodle without problems.

This does not mean that there is not a bug with 13.2.0, XS, and/or XSCE; but one thing you could try is to fully stop and restart the Browse activity after registering if the first login attempt does not work.  Sometimes I have found this helps.


On Tue, Aug 6, 2013 at 11:14 AM, Gonzalo Odiard <[hidden email]> wrote:
I don't have a school server to try.
You should fill a ticket on bugs.sugarlabs.org
cced: Manuel Quiñones, who maintain Browse activity.

Gonzalo


On Tue, Aug 6, 2013 at 12:08 PM, Jerry Vonau <[hidden email]> wrote:
Think it's more of a question of looking for confirmation. Is anybody else seeing this behavior on 13.2.0-13 on XO-1s when used with any version of school-servers? I'm at a loss trying to explain why this is occurring to Anna. With the noted behavior where would you file the bug report? OLPC is what I'm thinking but looking if someone else might be impacted also or can confirm this.

Jerry


On 6 August 2013 05:12, Gonzalo Odiard <[hidden email]> wrote:
There are a ticket filled?

Gonzalo


On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau <[hidden email]> wrote:
Great piece of deductive testing Anna, way to go. Forwarding for further investigation.

Jerry

---------- Forwarded message ----------
From: Anna <[hidden email]>
Date: 5 August 2013 15:02
Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable
To: xsce-devel <[hidden email]>


I just realized that someone will probably ask what's the most recent build where Moodle transparent auth did work.  Lucky for me, I just had to test one older.  Moodle transparent auth DOES work in 13.2.0-12.

So whatever broke client side Moodle transparent auth should be confined to 13.2.0-13.


On Mon, Aug 5, 2013 at 2:19 PM, Anna <[hidden email]> wrote:
I very recently upgraded my little herd of XOs to the latest stable build 13.2.0-13.  Unfortunately, something in that build has broken Moodle's transparent authentication.  When a registered client goes to http://schoolserver/moodle, all it gets is the login page.

Now, that's not unheard of, you can usually just click the "Home" button and get automatically logged in.  But when I've seen that before, the XO's SN is filled out in the Username field on the login page.  The 13.2.0-13 XO doesn't show that.  No matter what you click on in the Moodle login page, it never logs in.

To verify it was a client side issue, I flashed an XO-1 with 13.1.0 stable, and registered first to be admin.  I also registered a 13.2.0-13 as the second client.  On the 13.1.0, I can go to the Moodle homepage and it automatically logged me in.  I tried again to access the Moodle homepage on the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin XO, I went to Site Administration -> Users -> Accounts -> Browse list of users and saw both XOs listed.  It indicated that the 13.2.0-13 client had never logged in.

So, the user account is being created on the server for the 13.2.0-13 XO upon registration, but client side transparent authentication is not working.

To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I went to http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pl and the test was successful.

Now, I have successfully tested Moodle transparent auth with previous iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that broke transparent auth must have been relatively recent.

I took a look at the Browse Activity version between the two clients:
13.1.0 = Browse 149
13.2.0-13 = Browse 149.3

I knew it wouldn't make a difference, but I also tested the 13.2.0-13 as first registration and it doesn't care that its the admin user.  And also tested with a fresh flash to make sure there wasn't something sticky in there from a previous registration gumming things up.

I've tested this with the XSCE installed a couple days ago (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I also remembered I have an XS 0.6 (duh, Anna) and the results were the same.  I don't have an XS 0.7 installation, but I would expect the same results.

Since this is a client side issue, I'm not sure where to go from here as far as troubleshooting.

Anna 



_______________________________________________
Sugar-devel mailing list
[hidden email]
http://lists.sugarlabs.org/listinfo/sugar-devel





_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel




_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Martin Langhoff
On Tue, Aug 6, 2013 at 3:32 PM, Jerry Vonau <[hidden email]> wrote:
> This behavior was noted with XO-1s only, all others(1.5,1.75,4) appear work
> fine in testing.

That is _very_ weird. Does the affected unit have any problem reading
its own serial number or uuid? Does the Sugar Control Panel show the
serial number correctly?

cheers,



m
--
 [hidden email]
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Jerry Vonau-2


On 11 August 2013 10:14, Martin Langhoff <[hidden email]> wrote:
On Tue, Aug 6, 2013 at 3:32 PM, Jerry Vonau <[hidden email]> wrote:
> This behavior was noted with XO-1s only, all others(1.5,1.75,4) appear work
> fine in testing.

That is _very_ weird. Does the affected unit have any problem reading
its own serial number or uuid? Does the Sugar Control Panel show the
serial number correctly?

Good to hear from you Martin. Just to finish this thread off, I was not able to reproduce this behavior with the XO-1s that I have. This appears to affect Anna's machines only. Thanks for the hints to what might be the root cause.

Jerry



_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Martin Langhoff
On Sun, Aug 11, 2013 at 1:15 PM, Jerry Vonau <[hidden email]> wrote:
> Good to hear from you Martin. Just to finish this thread off, I was not able
> to reproduce this behavior with the XO-1s that I have. This appears to
> affect Anna's machines only. Thanks for the hints to what might be the root
> cause.

Thanks for the greeting! I had a season of detox after some severe
burnout. I'm spending this weekend at Fedora Flock for personal
enjoyment, and it's brought me back to the OLPC topic.

About Anna's machines -- I suspect either an old OFW or
bad/broken/misconfigured manufacturing data.

cheers,



m
--
 [hidden email]
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

David Farning
On Sun, Aug 11, 2013 at 3:20 PM, Martin Langhoff
<[hidden email]> wrote:
> On Sun, Aug 11, 2013 at 1:15 PM, Jerry Vonau <[hidden email]> wrote:
>> Good to hear from you Martin. Just to finish this thread off, I was not able
>> to reproduce this behavior with the XO-1s that I have. This appears to
>> affect Anna's machines only. Thanks for the hints to what might be the root
>> cause.
>
> Thanks for the greeting! I had a season of detox after some severe
> burnout. I'm spending this weekend at Fedora Flock for personal
> enjoyment, and it's brought me back to the OLPC topic.

Welcome back!

I look forward to seeing your head and opinions poking up now and again :)

> About Anna's machines -- I suspect either an old OFW or
> bad/broken/misconfigured manufacturing data.
>
> cheers,
>
>
>
> m
> --
>  [hidden email]
>  -  ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  ~ http://docs.moodle.org/en/User:Martin_Langhoff
> _______________________________________________
> Sugar-devel mailing list
> [hidden email]
> http://lists.sugarlabs.org/listinfo/sugar-devel



--
David Farning
Activity Central: http://www.activitycentral.com
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

Anna-2
In reply to this post by Martin Langhoff
I'm still seeing this issue sporadically on my XO-1 clients.  Surely not all the XO-1s (6-7) I'm testing with have bad manufacturing data.

Autologin does eventually work if I delete the cookies and try again.  Here's what I'm seeing:

Registered the XO, opened Browse, went to Moodle, confirmed no autologin
rm /home/olpc/.sugar/default/org.laptop.WebActivity/data/gecko/cookies.sqlite
Restart Browse, autologin works

Anna Schoolfield
Birmingham


On Sun, Aug 11, 2013 at 3:20 PM, Martin Langhoff <[hidden email]> wrote:
On Sun, Aug 11, 2013 at 1:15 PM, Jerry Vonau <[hidden email]> wrote:
> Good to hear from you Martin. Just to finish this thread off, I was not able
> to reproduce this behavior with the XO-1s that I have. This appears to
> affect Anna's machines only. Thanks for the hints to what might be the root
> cause.

Thanks for the greeting! I had a season of detox after some severe
burnout. I'm spending this weekend at Fedora Flock for personal
enjoyment, and it's brought me back to the OLPC topic.

About Anna's machines -- I suspect either an old OFW or
bad/broken/misconfigured manufacturing data.

cheers,



m
--
 [hidden email]
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff


_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel