[Building Sakai] Is there a way to get the username?

Steve Swinsburg steve.swinsburg at gmail.com
Tue Jan 14 16:37:59 PST 2014


Precisely. Its useful for some sort of personalisation, but obviously not
for anything that needs to be secured. I dont think any application would
expect that. The web content tool actually has a whole heap of parameters
so is the same, security wise:

# Expose a set of macros that the Web Content tool can use to
customise the URL for each user.
# You should understand the security implications of this before enabling.
# Note that you can create custom macros that expose properties but
they need to be specified in this list
# DEFAULT: ${USER_ID},${USER_EID},${USER_FIRST_NAME},${USER_LAST_NAME},${SITE_ID},${USER_ROLE}
# iframe.allowed.macros=${USER_ID},${USER_EID},${USER_FIRST_NAME},${USER_LAST_NAME},${SITE_ID},${USER_ROLE},${SESSION_ID},${SITE_PROP:course-unique-id},${SITE_PROP:course-section-key}

I think for Paul's purposes he has a range of options available to use
here, depending on complexity and security required.

Anyone performing any integration needs to understand the security
implications of the approach.

cheers,
Steve



On Wed, Jan 15, 2014 at 11:14 AM, Matthew Jones <matthew at longsight.com>wrote:

> I don't know, because the user sees the link for
> https://www.somewhere.com?person=Steve copies and pastes the url and puts
> in https://www.somewhere.com?person=Paul and it works? User names and
> eid's are generally pretty trivial to guess, and often publicly available.
> Basically it just means the external site can't trust the information any
> further than saying
>
> "Hi there Steve!"
>
> If that's all he wants, great! If he wants to have it do something useful
> like some type of personalized work, then it's not too useful. I guess that
> wasn't specified. I can't think of any case where I'd have an external
> service that only wants this information though. Even in the original web
> content version of it, the only really useful thing you could pass was the
> SESSION_ID, and you could use this on the external service to make a web
> service call back into the Sakai system to do useful processing. (And this
> is also something that was is slightly more difficult to spoof for someone
> other than yourself without using some type of exploit)
>
>
> On Tue, Jan 14, 2014 at 6:59 PM, Steve Swinsburg <
> steve.swinsburg at gmail.com> wrote:
>
>>
>> Why would you need encryption or verification? The instructor sets up the
>> links and locks down editing. The macros are filled in at request time for
>> the user that clicks the link, like the web content tool. The link then
>> looks like http://www.somewhere.com?person=Steve. It should be obvious
>> to all that if something has such simple 'security' requirements as passing
>> in the name as a parameter, then anyone with the link can change it. It's
>> not designed for actual secure applications just like the web content tool
>> isn't.
>>
>> Pauls original request can be met by this solution
>>
>>
>>  http://externalSystem.edu/program.php?userName=*<current user name>*
>> &otherParam=value
>>
>>
>> On Wed, Jan 15, 2014 at 10:41 AM, Matthew Jones <matthew at longsight.com>wrote:
>>
>>> Cool Steve, I didn't see that feature. Should be included in the Sakai
>>> 10 documentation.
>>>
>>> I guess the only thing that would mean is that they wouldn't be verified
>>> links, since any user could essentially put whatever they wanted, but it
>>> would be convenient if you weren't interested in that. You'd have to send
>>> it over encrypted or have to verify it back on a direct provider, but then
>>> you're basically getting into as much work as an LTI style interface anyway.
>>>
>>>
>>> On Tue, Jan 14, 2014 at 6:10 PM, Steve Swinsburg <
>>> steve.swinsburg at gmail.com> wrote:
>>>
>>>> Web links in resources do (now) allow macros:
>>>> https://jira.sakaiproject.org/browse/SAK-23587
>>>> So a bunch of links could be setup in resources then LessonBuilder can
>>>> just add those. This was the exact use case for this functionality.
>>>>
>>>> Alternatively, you can use the /direct/session entityprovider to get
>>>> data about the current user, parse that and make the link. That could be
>>>> done in javascript if its allowed in the markup block.
>>>>
>>>>
>>>> On Wed, Jan 15, 2014 at 3:10 AM, Matthew Jones <matthew at longsight.com>wrote:
>>>>
>>>>> I agree, I think LTI would be the *best* way to go, and since the
>>>>> external app is in PHP, it should be pretty easy to convert it over to
>>>>> except a launch via LTI. Then the user can add the tool via LTI.
>>>>>
>>>>> The web content tool supports passing user information as
>>>>> macros/parameters, but it looks like Lessons uses URL links from resources
>>>>> which don't. It would be probably be a useful feature if it did support
>>>>> this (adding a URL into resources that had expanded parameters like web
>>>>> content) and that doesn't seem like it would take a lot of effort, though
>>>>> with this method anyone could pass whatever values they wanted without
>>>>> verification.
>>>>>
>>>>> I like the second idea better than the links. If the external service
>>>>> could make a jsonp request back and get the data it needed, and then
>>>>> immediately POST it, that would work too. This is kind of like what LTI
>>>>> does though with additional verification, information and access to
>>>>> services in the consumer. The current user is available in /direct/user but
>>>>> subject to same origin policies.
>>>>>
>>>>> You'd really want something that the user can't tamper with, unless
>>>>> you were *only* using it for display purposes.
>>>>>
>>>>>
>>>>> On Tue, Jan 14, 2014 at 10:52 AM, Noah Botimer <botimer at umich.edu>wrote:
>>>>>
>>>>>> So, you're looking for a link that a learner would click to go to an
>>>>>> external, personalized URL?
>>>>>>
>>>>>> There are a couple of ways to manage this...
>>>>>>
>>>>>> 1. Implement the IMS LTI spec on the external system so it is a Tool
>>>>>> Provider -- this is the most complete and secure way, but obviously more
>>>>>> involved
>>>>>>
>>>>>> 2. Implement a quick Servlet / EntityProvider to look up the current
>>>>>> user and issue a redirect with the appropriate destination -- the links
>>>>>> would be back to the Sakai instance (and be static, not including username)
>>>>>>
>>>>>> Depending on how user-friendly you need this to be, it may involve an
>>>>>> addition to Lessons or a CKEditor plugin.
>>>>>>
>>>>>> Another hackish angle is that you can use the existing
>>>>>> EntityProviders to get current user information via AJAX and rewrite the
>>>>>> link or update window.location -- this would require some scripting mojo.
>>>>>>
>>>>>> Thanks,
>>>>>> -Noah
>>>>>>
>>>>>> On Jan 14, 2014, at 10:18 AM, Paul Dagnall wrote:
>>>>>>
>>>>>> Adrian - Is the UserDirectoryService exposed to the content area
>>>>>> editable by the ckeditor though? My goal is for content creators to be able
>>>>>> to make lessonbuilder content that would include such a link.
>>>>>>
>>>>>> Paul Dagnall
>>>>>> Application Developer & Administrator
>>>>>> University of Dayton
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 14, 2014 at 10:01 AM, Adrian Fish <
>>>>>> adrian.r.fish at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Paul,
>>>>>>>
>>>>>>> So, you're rendering a link in a lessonbuilder page, and you want to
>>>>>>> embed the current user's name in it? In that case, just use
>>>>>>> UserDirectoryService.getCurrentUser, which will get you a Sakai User
>>>>>>> object. You can then call getFirstName, getLastName and getEid on that
>>>>>>> object.
>>>>>>>
>>>>>>> If you have a look in ShowPageProducer, you'll see examples of that
>>>>>>> method in use.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Adrian.
>>>>>>>
>>>>>>>
>>>>>>>  On 14 January 2014 14:51, Paul Dagnall <pdagnall1 at udayton.edu>wrote:
>>>>>>>
>>>>>>>>  Hi
>>>>>>>> Does anyone know of a way to get the current user's username and
>>>>>>>> expose it so it can be accessed by that user from a sakai content page?
>>>>>>>>
>>>>>>>> There is an external system we are trying to access from a html
>>>>>>>> link in the Lessons tool. Basically we'd like the link to be something like
>>>>>>>> this:
>>>>>>>>
>>>>>>>> http://externalSystem.edu/program.php?userName=*<current user
>>>>>>>> name>*&otherParam=value
>>>>>>>>
>>>>>>>> I know there's a webservice that will get me the user name if I
>>>>>>>> have the session id, which I don't think is available in that scope.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Paul Dagnall
>>>>>>>> Application Developer & Administrator
>>>>>>>> University of Dayton
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sakai-dev mailing list
>>>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>>>
>>>>>>>> TO UNSUBSCRIBE: send email to
>>>>>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>>>>>> "unsubscribe"
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> sakai-dev mailing list
>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to
>>>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>>>> "unsubscribe"
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> sakai-dev mailing list
>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to
>>>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>>>> "unsubscribe"
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sakai-dev mailing list
>>>>> sakai-dev at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>
>>>>> TO UNSUBSCRIBE: send email to
>>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>>> "unsubscribe"
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140115/94ceccbe/attachment.html 


More information about the sakai-dev mailing list