Transfer Script

Question

I am trying to restrict access to a course page by password protecting it. I have went into the edit course page and added in custom permission added download to USHistory@urn:mace:..... Ok now i tried to go into the transfer script and add the following credential;
String[] credentialsArray = { USHistoryCredential };
String displayName = "USHistory";
String emailAddress = "[email protected]";
String username = "USHistory";
String userIdentifier = "password";
What am I doing wrong cause this isn't working.
Thanks

Answer 1

Hmm ... lemme see if I can explain. I'm not sure I'm going to do your question justice ... but I'll try.
The first thing to know is this: Apple does not hold any userid/password info for an iTunes U site ... with one, very very specific, exception. But that exception does not come into play for you in this instance. The basic rule of thumb is that Apple does not know any of your users ... Apple only deals with credentials.
In iTunes U, what you do is authenticate your users your own way (whatever that is ... Banner, Active Directory, LDAP with an MD5 hashed password store, Kerberos). Your authentication process basically gives a yes/no answer ... "such-and-such user is valid at our school" or "such-and-such user is not part of our school". If you get a "yes" response from your authentication system, you generate a set of credentials for your user and pass them to Apple. Based on the credentials you assign to your user, Apple grants him/her access to specific courses and iTunes U tracks.
As I am fond of saying, an iTunes U credential is like a high school hall pass. The hall pass itself is a piece of plastic or paper or cardboard ... it could be laminated ... but it only says one thing, "Let the bearer of this pass go to the lunchroom," or, "Let the bearer of this pass go to the bathroom," or, "Let the bearer of this pass go to the principal's office" ... like that. If a teacher stops a student in the hallway, he/she might ask, "Can I see your hall pass?" The teacher will not necessarily know who the student is ... all he/she needs to know is that the student has a valid hall pass. In fact, the beauty of the hall pass system is that no teacher need know the name of any particular student ... all that matters is that someone the teacher trusts gave the student a valid hall pass. iTunes U works the same way ... Apple "trusts" you to validate your users and assign them the right set of hall passes. That trust is established with your shared secret ... only you and Apple know what it is. But when Apple sees your users, it only sees credentials ... the hall passes ... it doesn't know your users' names, passwords, usernames, etc.
So you might be asking, "Hey Rich, you say that Apple doesn't care about my users, so why does the example transfer script have 'username' in it, what's up with that?" Well, the answer is that you can, if you like, tell Apple to record identity information about your users and pass it back to you later in site usage logs ... but you do not have to pass identity information at all ... you can leave "username", "e-mail", "name" ... you can leave all that stuff blank and iTunes U would still work. However, when Apple sends you your site usage logs, all you'll see is that some "visitor" downloaded a certain track at a certain time. If you want to know who that was, you have to tell Apple to record that for you by sending a username along with a credential set. But Apple does not "see" your usernames/e-mail addresses/whatnot ... all Apple cares about is that credential set. Apple merely records user info to send back to you "as is". If you send bogus user info, for example, Apple would dutifully record it in logs and send it back to you the way you sent it. But get a credential wrong, and iTunes U will not work.
So display name, username, user identifier, and e-mail address are not used by Apple at all in iTunes U. They are just recorded and sent back to you "as is" in usage logs -- they are just means for you to figure who's who when looking at logs. Apple does not encrypt them ... they are sent in the clear. For that reason, I would strongly urge you to not to send password info in that user identifier string.
To restrict access to something in iTunes U, a credential is only half the story ... in iTunes U, there is something called a "permission". A permission is the combination of a credential and an access level. For example, a permission might look like this:
Student@urn:mace:itunesu.com:sites:myu.edu DOWNLOAD
or:
Administrator@urn:mace:itunesu.com:sites:my.edu EDIT
When you create a permission in iTunes U, you're saying that if someone comes to a "place" in your site, and he/she bears a certain credential ("Student" or "Administrator"), that he/she should have a certain access level ("can browse and download content" or "can edit this page") for that "place". Notice how usernames/passwords aren't a part of this scheme ... if you bear the "Student" credential, you can "DOWNLOAD" whereas if you bear the "Administrator" credential, you can "EDIT". Apple does not need to know who's who ... you've already authenticated your people and told Apple about the the creds/access that should be granted. Apple trusts you because you signed the user's request with the shared secret that only you and Apple know.
Make sense?