9016 Views 4 Replies Latest reply: Feb 26, 2008 11:22 AM by richwolf
Huh, sounds similar to something we ran into in the past (max characters in a URL in IE) but I thought that was more or less resolved and we are passing like a million credentials for everyone at this point. To help folks who know more than both of us, could you define the limitations to URL size that you see, that are causing you this problem?
Oh, and at least in our case we are using Shibboleth and only passing the relevant attributes (isMemberOf and eduCourseMemeber), although we're thinking about mashing both of those into eduCourseEntitlement on send-time. Also, our administrators are over the whole site so I actually have less relevant credentials than some folks enrolled in classes, who can build up 40 or so eduCourseMember credentials over their tenure.
Well, here are some data points that I hope you will find useful. Overall, I think Ben has this about 100% correct.
A token string can, according to Apple, contain up to one-hundred credentials. That's a lot of credentials. Further, each credential can be as long as 1,024 characters. I wouldn't say it's impossible that someone could hit those numbers ... but they are pretty high.
In practical terms, you're limited to the length of the URL that any browser can deal with. Sadly, it looks like the one with the greatest issue is Explorer. In Explorer, no URL can have more than 2,083 characters in it (unless you are POSTing). So I would look at 2,083 as sort of an absolute maximum ... actually, a bit less than that once you take into account signature, identity, timestamp, and base URL. Ballpark, I'd go with 2000 characters.
But 2000 characters can pack a lot of credentials ... certainly as many as forty or fifty (maybe more than that ... depending on how you set them up). So, "typically" you can expect to go anywhere from about 50 credentials, to the theoretical maximum of 100 ... depending on their respective size ... and keep both Apple and Microsoft happy. The other browsers are way more robust and can easily handle 100 credentials.
My advice would be that you can always grow into an increasingly complex credentialling scheme ... you can experiment on a small scale and ramp up. Also recall that permissions flow down in an iTunes U site. That is, you can assign a generic credential to everyone at the top level of your site, and refine access as users drill down into a site. You could give administrators a credential which marks them as such, then let them have broad powers over large sections of your site. Because of their admin credential, they wouldn't need to carry a whole set of others (because the access you have at any "place" in an iTunes U site is the most access that any of the credentials you hold allows at that "place").
Thanks to both of you for your replies. They were helpful in thinking through this problem. The issue we have is that we have over 100 individuals who have over 100 course enrollments across all of our active semesters in our LMS. So that means we have a decent sized population for which we couldn't sent the entire list of their enrollments as credentials.
However, while talking with another member of my team, he came up with what I hope will be a perfect and elegant solution. We're going to try, upon login, to pull a list of available credentials from iTunesU and compare that list with the list of enrollments, group memberships, etc. from our local identity store and only pass those that actually exist in iTunesU. This should solve all of the issue since it will likely not happen that a person has over 50-100 actual iTunesU credentials that apply to them. (if we end up with that sort of adoption we have a much bigger set of issues to deal with anyways.
Thanks again for the input and any feedback on our approach here is welcome as well.
Ahhhh ... I think I understand your problem better now.
Your LMS contains all the credentials any user might ever hold ... and not just those that user holds during any particular semester. So when you pass credentials, many might not yet be "in play" so-to-speak. In that case, I really love your solution ... I think it is correct. What's even more nifty, is that you need not necessarily get a list of creds with every access to iTunes U ... since creds are orthogonal to users, your system can periodically poll iTunes U to get an updated list of creds and cache it locally.