[Deploying Sakai] Hide Sakai login and password reset

[Matthew Jones]

Ah, I see, I never noticed these 5. They would likely satisfy John's
first request if using the stock UserDirectoryService.

The relevant functions:
user.upd.own
user.upd.own.email
user.upd.own.name
user.upd.own.passwd
user.upd.own.type

-Matthew

On Thu, Aug 13, 2009 at 1:00 PM, Stephen
Marquard<stephen.marquard at uct.ac.za> wrote:
> Actually there are some permissions that you can set in the
> !user.template.XXX (where XXX = account types) that determine what users
> can update, e.g. you can prevent users from changing their own name.
>
> Cheers
> Stephen
>
>>>> Matthew Jones <jonespm at umich.edu> 8/13/2009 5:55 PM >>>
> I'm not entirely sure on the first question. For internal users, a
> regular access user can only modify their name, email and password. An
> admin user can change a user id. Perhaps you were viewing this as
> admin.
>
> If you are using a provider then the lookups are different. It's
> pulling the details of the User object from the external provider.
> (getUser) The provider supplies the email address. To edit, your
> provider would have to have extend the UserDirectoryService and allow
> you to specify which of these details back to the external system.
>
> If you wanted to have certain fields not editable and you're not using
> a provider it looks like you'd likely have to change the velocity file
> in the source to disable/remove these inputs.
> (user/user-tool/tool/src/webapp/vm/user/chef_users_edit.vm) For vm's
> you can edit them in the webapp and rezip them into the war to save on
> the rebuild, though loading the changes will require a app
> redeploy/restart.
>
> It's in webapps/sakai/user-tool/vm/user/chef_users_edit.vm
> Edit file and repackage:
> jonespm at localhost:/usr/local/tomcat/webapps/sakai-user-tool$ zip
> ../sakai-user-tool.war vm/user/chef_users_edit.vm
> updating: vm/user/chef_users_edit.vm (deflated 77%)
> --------------
> For the second question, you can block with a context in tomcat, or if
> you have Apache/IIS in front you can also use some rewriting/location
> blocking there.
>
> For tomcat add these to the host block in conf/server.xml
> (Reference:
> http://serverfault.com/questions/28337/how-to-block-access-to-a-file-from-being-served-by-tomcat)
>      <Host name="localhost" appBase="webapps"
>       unpackWARs="true" autoDeploy="true"
>       xmlValidation="false" xmlNamespaceAware="false">
>      . . .
>
>       <Context path="/portal/xlogin" docBase="" >
>           <Valapp
> className="org.apache.catalina.valapps.RemoteAddrValapp" deny="*" />
>       </Context>
>
>       <Context path="/portal/login" docBase="" >
>           <Valapp
> className="org.apache.catalina.valapps.RemoteAddrValapp" deny="*" />
>       </Context>
>       . . .
>
> -Matthew
>
> On Thu, Aug 13, 2009 at 9:54 AM, Grossman,John
> E<john.grossman at mdanderson.org> wrote:
>> In Sakai 2.6 we are authenticating users via LDAP and Sakai web
> services.
>> We’d like to do two things:
>>
>>
>> Prevent users from changing  user ids and creating new passwords on
> the
>> Account Details page while still allowing them to change their email
>> address.
>> Block access to portal/login and portal/xlogin
>>
>>
>> Any suggestions on the best/easiest way to accomplish this?
>>
>> John Grossman
>> The University of Texas M. D. Anderson Cancer Center
>> john.grossman at mdanderson.org
>>
>>
>> _______________________________________________
>> production mailing list
>> production at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/production
>>
>> TO UNSUBSCRIBE: send email to
> production-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>>
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to
> production-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
>