C# Provider BLTI

[Carlos Ors]

Hi,

We are likely to use BLTI with an integration project that we are carrying out with the creators of the comercial lms Intelligent Web Teacher (IWT), which is .NET.

My question is:

¿Is there any Oauth implementation for .NET (c# ) for writting the BLTI provider part ? If so, ¿does it work well or it has any known problem?

I would be very grateful  if someone could pass me any provider code snipped just to have an example of use.

Thank you in advance.

--
Carlos Ors Giraldo
Cap de Projectes de Tecnologia Educativa
Universitat Oberta de Catalunya

93 253 (5770) | co...@uoc.edu
Tibidabo 3 (Av. Tibidabo 45-47)
http://learningtechnologies.uoc.edu/carles-ors/



Aquest missatge s´adreça exclusivament a qui va destinat i pot contenir informació privilegiada o confidencial i dades de caràcter personal, la difusió de les quals és regulada per la Llei orgànica de protecció de dades i la Llei de serveis de la societat de la informació. Si no sou la persona destinatària indicada (o la responsable de lliurar-lo a qui va destinat), no heu de copiar aquest missatge ni lliurar-lo a tercers per cap concepte. Si heu rebut aquest missatge per error o l´heu aconseguit per altres mitjans, us demanem que ens ho comuniqueu immediatament per aquesta mateixa via i l´elimineu irreversiblement.


Abans d´imprimir aquest missatge electrònic penseu en el medi ambient.

[csev]

I would start here - let me know what you find - I am not a .NET guy so I don'

http://www.mirlearn.com/

http://mir.codeplex.com/

/Chuck

--
You received this message because you are subscribed to the Google Groups "IMS Developer Mailing List" group.
To post to this group, send email to ims...@googlegroups.com.
To unsubscribe from this group, send email to ims-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ims-dev?hl=en.

[Bryan Holland]

Hi Carlos,

 

We wrote mir to be an LTI provider and consumer.  If you look at the code in http://mir.codeplex.com/ you can get an idea of how to implement.  The oauth piece is in there.

 

Bryan Holland

LearnGauge, LLC

Phone (517) 639-0224

Cell (517) 281-9155

Fax (866) 213-7298

bhol...@learngauge.com

--

[Carlos Ors]

Hi,

I want to share my short experience with C#.NET and Oauth.

We have decided to use the C#.NET Oauth implementation of dev-tools https://github.com/bittercoder/DevDefined.OAuth/

  (which is the continuation of dev-tools as it is explained in http://code.google.com/p/devdefined-tools/wiki/OAuth ).

So far, we have achieved the signature validation thanks to encoding some parameters (coming from php and java consumer) into Base64 to avoid problems of the Spanish graphic accent.

For the moment, this implementation seems to behave well. I will notify if I come across something working bad.

Carlos.

2010/11/12 Bryan Holland <bhol...@learngauge.com>

[csev]

Carlos,

It seems that every OAuth implementation in C# has an encoding bug - it encodes special characters improperly.   The original C# reference implementation code from oauth.net was broken and folks that make copies of the code maintain the brokenness.   It works for non-special characters - but fails with special characters (even space fails in certain situations).

My guess is that the reason that your extended characters do not work is because of the C# bugs - not because OAuth. 

I would suggest that you go to 

www.imsglobal.org/developers/BLTI/lms.php 

And put in Spanish characters and then send those characters to the tool.php script, also on that same server.   If this call fails, then we have a problem.   If calling from PHP to PHP works and transports Spanish characters fine, then your C# code likely has the encoding bug and we should fix it.

What I would really like is once you fix it that you provide me with a copy of the fixed code so I can add it to our SVN servers so we stop this cycle of C# breaking because this bug just never seems to get fixed.

Thanks.

/Chuck

[Antoni Bertran]

Hello Chuck, but  we also tryed to call PHP to Java and Java to PHP and fails with spanish characters (such as ñ, á, ä, à, etc.)

Then we codified in base64 and everything works!

Cheers,

Antoni Bertran Bellido
3&Punt Solucions Informàtiques SLL
935325991 - 935325992
C.Aragó 390, àtic 3
08013 Barcelona
www.tresipunt.com
Tel 935325991
Mob 677410818
Fax 935325992

Aquest missatge pot contenir informació confidencial, en propietat o legalment protegida i està destinada únicament per l'ús de la persona destinataria. Si vostè no és la persona destinataria d'aquest missatge, per la present se'l comunica que no ha d'emprar, difondre, copiar de cap manera, ni emprendre cap acció en relació amb ella. Si vostè ha rebut aquest missatge per error, per favor li preguem que l'esborri, així com qualsevol còpia del mateix i notifiqui aquest fet al remitent. 
 Este mensaje puede contener información confidencial, en propiedad o legalmente protegida y está destinada únicamente para el uso de la persona destinataria. Si usted no es la persona destinataria de este mensaje, por la presente se le comunica que no tiene que utilizar, difundir, copiar de ninguna manera, ni emprender ninguna acción en relación con ella. Si usted ha recibido este mensaje por error, por favor le rogamos que lo borre, así como cualquier copia del mismo y notifique este hecho al remitente.

2011/1/24 csev <cs...@umich.edu>

[csev]

Yikes - that is a bug.   Dang.

/Chuck

[csev]

So I just tried it, setting the resource title to the characters you sent me and it worked with my IMS test harness.

I tried it with Moodle and Sakai and the signatures were fine - but the characters were wrong.

There is clearly a bug somewhere - but switching to Base-64 is not the right way to fix it otherwise everyone goes interoperable.

I am going to guess that somewhere in each of these code bits, I am not getting the characters properly encoded. The key is to figure out why or where Moodle and Sakai are loosing their way. I am so not an expert on sending non ASCII data in forms. I will look around a bit and try to learn - any help is welcome.

I am 99% sure the problem is *not* OAuth's ability to handle Spanish characters - but instead it is a flaw in my sample code - either the code that accepts user input - or the code that makes the auto-submit form or the code that ultimately displays the data in my test harness.

PDF's attached.

/Chuck

[csev]

More playing - in Sakai in FireFox, the characters go through fine and the signature works fine.  I attach a PDF and view source of the form submission.

The only weird bit is that in my php test harness the character set is ISO-8859-1 and in Sakai it is UTF-8.

I found this about C#'s OAuth:

http://blog.stephendenton.com/code/a-proper-urlencode-function-for-oauth-in-c-sharp/

Still digging...

/Chuck

On Jan 25, 2011, at 3:56 AM, Antoni Bertran wrote:

[Antoni Bertran]

Wihere I can download jar or source code of blti for Java? problably I have to update to the last version

This is the url ? http://ims-dev.googlecode.com/svn/trunk/basiclti/

I see no difference between my code and this subversion...

Cheers

Antoni Bertran Bellido
3&Punt Solucions Informàtiques SLL
935325991 - 935325992
C.Aragó 390, àtic 3
08013 Barcelona
www.tresipunt.com
Tel 935325991
Mob 677410818
Fax 935325992

Aquest missatge pot contenir informació confidencial, en propietat o legalment protegida i està destinada únicament per l'ús de la persona destinataria. Si vostè no és la persona destinataria d'aquest missatge, per la present se'l comunica que no ha d'emprar, difondre, copiar de cap manera, ni emprendre cap acció en relació amb ella. Si vostè ha rebut aquest missatge per error, per favor li preguem que l'esborri, així com qualsevol còpia del mateix i notifiqui aquest fet al remitent. 
 Este mensaje puede contener información confidencial, en propiedad o legalmente protegida y está destinada únicamente para el uso de la persona destinataria. Si usted no es la persona destinataria de este mensaje, por la presente se le comunica que no tiene que utilizar, difundir, copiar de ninguna manera, ni emprender ninguna acción en relación con ella. Si usted ha recibido este mensaje por error, por favor le rogamos que lo borre, así como cualquier copia del mismo y notifique este hecho al remitente.

2011/1/25 csev <cs...@umich.edu>

[csev]

Yes - that is the latest version and the version that is in Sakai and OLAT.

I am running to each a class - but somewhere in the OLAT source is their support for BLTI and it has a pom.xml that points right to the latest jar in the Sakai repo.

/Chuck

[csev]

Antoni,

I finally got back to this issue with the improperly viewed characters.  This is how I reproduced the problem:

Use Sakai, Moodle, and my IMS Test Harness (lms.php) at www.imsglobal.org.  I used Safari on the Max, FF on the Mac and IE on Windows.

I would make a Basic LTI Tool placement with the title as " (such as ñ, á, ä, à, etc.)"  (your characters) and then launch from the various LMS's to my test harness.

In all cases, the signature verified properly.   In Firefox the characters displayed properly but in Safari and IE the characters did not show properly in tool.php - as if they had been mangled.   But with the signature verifying, it did not seem likely that the data had been mangled in transit - so that was curious.

I added some debug print in the test tool.php to show the character set of each parameter and it properly noticed that the resource title was UTF-8 while the rest of the fields were ASCII.

However the characters displayed improperly with upper case A and some other character where the lower case letters were supposed to appear.

I played a bunch adjusting the page submitting the form, adding character set encodings, content-types, etc - and while all those things are good, they did not fix the problem of the title looking bad in IE and FF in my test harness.

Then I cleaned up the HTML produced by the lms.php and tool.php, adding headers and meta tags for the character set and everything started working - the signatures verified and the characters displayed properly everywhere from all three launches and from all three browsers.

So, I think that things are back in order and then only broken bit was my test harness and now that is updated to properly display UTF-8 Characters in its response.

I still have an guess that the C# signature code is broken - that is leading to failed signatures - but at least (hopefully) my test tools should not mislead you as much as they did

Let me know if this helps or if your testing verifies or contradicts my testing.

Thanks for your patience.

/Chuck

[Antoni Bertran]

Hello today I tryed with Sakai 2.7.1 with BLTI support (latest of trunk) from source code. 

Then I tryed with "ñ" versus http://www.imsglobal.org/developers/BLTI/tool.php and I get error

And I get this error:

user_id=admin (ASCII)
context_id=123 (ASCII)
context_title=a�a (UTF-8)

I don't know if the problem is this UTF-8, I'm using embedded database of sakai. Is it possible???

Regards,

Antoni Bertran Bellido
3&Punt Solucions Informàtiques SLL
935325991 - 935325992
C.Aragó 390, àtic 3
08013 Barcelona
www.tresipunt.com
Tel 935325991
Mob 677410818
Fax 935325992

Aquest missatge pot contenir informació confidencial, en propietat o legalment protegida i està destinada únicament per l'ús de la persona destinataria. Si vostè no és la persona destinataria d'aquest missatge, per la present se'l comunica que no ha d'emprar, difondre, copiar de cap manera, ni emprendre cap acció en relació amb ella. Si vostè ha rebut aquest missatge per error, per favor li preguem que l'esborri, així com qualsevol còpia del mateix i notifiqui aquest fet al remitent. 
 Este mensaje puede contener información confidencial, en propiedad o legalmente protegida y está destinada únicamente para el uso de la persona destinataria. Si usted no es la persona destinataria de este mensaje, por la presente se le comunica que no tiene que utilizar, difundir, copiar de ninguna manera, ni emprender ninguna acción en relación con ella. Si usted ha recibido este mensaje por error, por favor le rogamos que lo borre, así como cualquier copia del mismo y notifique este hecho al remitente.

2011/2/6 csev <cs...@umich.edu>

[csev]

Antoni,

This could be because of Sakai 2.7.1 - I did make an improvement with Sakai yesterday

https://jira.sakaiproject.org/browse/BLTI-101

That was more explicit about UTF-8.   SO try to reproduce this with one of the Sakai nightly servers at

http://nightly2.sakaiproject.org/

Just make an account.  I used one of those servers and made an account with the "n-squiggle" character and also put it else where in the launch data.

I made this little screen cast that walks through things working.

http://www-personal.umich.edu/~csev/tmp/playing-with-basiclti-sakai.mov

Tell me what I am doing right or wrong.   Also, did it work with Moodle?    If this works with Sakai trunk and not 2-7, I can probably get the latest code pushed back into the 2-7-x branch.

/Chuck

--
You received this message because you are subscribed to the Google Groups "IMS Developer Mailing List" group.
To post to this group, send email to ims...@googlegroups.com.
To unsubscribe from this group, send email to ims-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ims-dev?hl=en.

<Error Sakai BLTI TOOL.png>

[Antoni Bertran]

Dr. Chuck today I'm trying in Windows and works! (with showing encoding problems) but verifies the signature.

Now I'm trying to do it working in Linux (where not verify the signature)

Any progress I will notice you.

Antoni Bertran Bellido
3&Punt Solucions Informàtiques SLL
935325991 - 935325992
C.Aragó 390, àtic 3
08013 Barcelona
www.tresipunt.com
Tel 935325991
Mob 677410818
Fax 935325992

Aquest missatge pot contenir informació confidencial, en propietat o legalment protegida i està destinada únicament per l'ús de la persona destinataria. Si vostè no és la persona destinataria d'aquest missatge, per la present se'l comunica que no ha d'emprar, difondre, copiar de cap manera, ni emprendre cap acció en relació amb ella. Si vostè ha rebut aquest missatge per error, per favor li preguem que l'esborri, així com qualsevol còpia del mateix i notifiqui aquest fet al remitent. 
 Este mensaje puede contener información confidencial, en propiedad o legalmente protegida y está destinada únicamente para el uso de la persona destinataria. Si usted no es la persona destinataria de este mensaje, por la presente se le comunica que no tiene que utilizar, difundir, copiar de ninguna manera, ni emprender ninguna acción en relación con ella. Si usted ha recibido este mensaje por error, por favor le rogamos que lo borre, así como cualquier copia del mismo y notifique este hecho al remitente.

2011/2/8 csev <cs...@umich.edu>

Antoni,

This could be because of Sakai 2.7.1 - I did make an improvement with Sakai yesterday

https://jira.sakaiproject.org/browse/BLTI-101

That was more explicit about UTF-8.   SO try to reproduce this with one of the Sakai nightly servers at

http://nightly2.sakaiproject.org/

Just make an account.  I used one of those servers and made an account with the "n-squiggle" character and also put it else where in the launch data.

I made this little screen cast that walks through things working.

http://www-personal.umich.edu/~csev/tmp/playing-with-basiclti-sakai.mov

Tell me what I am doing right or wrong.   Also, did it work with Moodle?    If this works with Sakai trunk and not 2-7, I can probably get the latest code pushed back into the 2-7-x branch.

/Chuck

On Feb 7, 2011, at 12:01 PM, Antoni Bertran wrote:

Hello today I tryed with Sakai 2.7.1 with BLTI support (latest of trunk) from source code. 

Then I tryed with "ñ" versus http://www.imsglobal.org/developers/BLTI/tool.php and I get error

And I get this error:

user_id=admin (ASCII)
context_id=123 (ASCII)
context_title=a�a (UTF-8)

I don't know if the problem is this UTF-8, I'm using embedded database of sakai. Is it possible???

Regards,

[csev]

I really think that this is an encoding problem somewhere. In particular because browsers do a lot of guessing when it comes to document encoding.

The problem can be:

(a) With the generated HTML from the consumer that contains the form submission

(b) With how the browser interprets the form page from the consumer as it submits it to the provider

(c) With how the provider interprets the incoming post data with respect to encoding

(d) With how the provider indicates encoding on the page it displays

(e) How the browser interprets the page from the provider

If the signature fails, it is likely because of a problem a-c.

If the signature succeeds and the data looks bad it is likely because of a problem in c-e

If the signature succeeds and the data looks bad, an alternate explanation is that somehow a-c are broken but in the same way. The consumer generates no UTF data but the provider detects the encoding so the data is matches across the transaction but is somehow garbled.

Some of this is hard to debug because it depends on which browser. ANd some browsers have better debugging of this than others.

/Chuck