[#BLTI-23] ProviderServlet does not support context_id keys that conflict with siteId semantics

BasicLTI

ProviderServlet does not support context_id keys that conflict with siteId semantics

Created: 30-Jan-2010 09:42 Updated: 07-Mar-2010 06:54

Component/s:

Basiclti-portlet

Affects Version/s:

1.0.0-b01

Fix Version/s:

1.1.0-b01

Time Tracking:

Not Specified

Issue Links:

Relate

This issue relates to:

~~BLTI-24~~ Maximum length of a context_id is too constraining - migrate to SHA-1 hash for siteId

Description

« Hide

If the remote system passes any "unusual charcters" in the context_id key, ProviderServlet cannot find/or create the site. For example, "/" or "%" get mangled in the site creation process. Since we do not know what kind of characters will be used in external system keys, we should be more forgiving when we map to local keys.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Lance Speelmon added a comment - 30-Jan-2010 09:49

Base64 encode the context_id using the "modified Base64 for URL" algorithm which then becomes the local siteId. This algorithm is nice because the key can be reversed into the original context_id passed by the remote system. My only concern is that the encoded key may become too long be stored in the siteId column (i.e. violating DDL length constraints).

I have tested the fix and it works for the case:
context_id=/sites/foo-bar
where siteId becomes:
12345:/sites/foo-bar

If we discover that the siteId length becomes too long (i.e. the actual length of MIME-compliant base64-encoded binary data is usually about 137% of the original data length), then maybe we should use a SHA-1 on the context_id and then store it as a property on the site object for later reference.

Committed revision 73024.

[ Permlink | « Hide ]

Lance Speelmon added a comment - 30-Jan-2010 10:00

We should go ahead and merge this fix as it is better than what we had. However, with the following DDL:

CREATE TABLE SAKAI_SITE (
SITE_ID VARCHAR (99) NOT NULL,

That means the maximum size of a remote context_id would be approximately 99/1.37=72. To me 72 characters may be too limiting - especially since we prepend the LTI key. While I might advocate for increasing the column size on SAKAI_SITE.SITE_ID, I am not sure we want to tackle that in this project. Unless I hear a better idea, I will assume that the SHA-1 + site.property.context_id storage of original contetx_id is a reasonable approach.