Page 2 of 2

Welcoming script

Posted: Thu Mar 01, 2012 10:20 am
by 10119metux
tdesorbaix wrote:
As example, there is a user property to enable/disable the Calendar feature, but it can't be changed by the user, only the admins can change it.

Thats exactly what I meant. If this setting is stored in these properties, the user

can change it by sending proper requests, bypassing the admin's decision.
I'd consider this a security hole.

Welcoming script

Posted: Thu Mar 01, 2012 11:08 am
by tdesorbaix
What I am saying is that there is a soap request to change user preferences, not for changing user properties.
the request to change the user property to enable/disable the Calendar feature is available on the admin console side, not on the client side.

Welcoming script

Posted: Thu Mar 01, 2012 11:20 am
by 10119metux
tdesorbaix wrote:What I am saying is that there is a soap request to change user preferences, not for changing user properties.
the request to change the user property to enable/disable the Calendar feature is available on the admin console side, not on the client side.

Just to make sure, we're not talking about different things:
#1: you've been capable of writing new user properties value downto ldap using a zimlet (client side java script code)

#2: the user calendar flag is stored in that properties field in ldap
Right ?

Welcoming script

Posted: Fri Mar 02, 2012 3:21 am
by tdesorbaix
10119metux wrote:
#1: you've been capable of writing new user properties value downto ldap using a zimlet (client side java script code)



Yes, the javascript call a soap request (so sent to the server to modify the ldap) that modify user preferences.
10119metux wrote:
#2: the user calendar flag is stored in that properties field in ldap



Not one properties field, but several fields each defining a property.
And yes those fields are stored at the same place, but the LDAP modification is done on server side after the reception of the soap request.

So I suppose that zimbra when it manage the soap request, check if the value the soap request ask to modify is in the list of the value a user can change.

Welcoming script

Posted: Fri Mar 02, 2012 11:39 am
by 10119metux
tdesorbaix wrote:
And yes those fields are stored at the same place, but the LDAP modification is done on server side after the reception of the soap request.

So I suppose that zimbra when it manage the soap request, check if the value the soap request ask to modify is in the list of the value a user can change.

Okay, let me summarize what I understood so far ... please correct me if I'm wrong:
* user properties are hold within the user objects in LDAP

* js client code holds them and allows arbitrary changes and adding new ones locally

* it writes them back to LDAP via an SOAP call

* that SOAP call will protect specific properties that may not be changed by the user.
Right ?
By the way: do those additional properties easily survive an upgrade ?

(you know, LDAP schemata tend to be incompatible between different

ZCS versions and the update process handles the conversion).

Welcoming script

Posted: Mon Mar 05, 2012 4:28 am
by tdesorbaix
10119metux wrote:
* js client code holds them and allows arbitrary changes and adding new ones locally



It can change values but not create new fields.

Zimlets user properties is one field, with multi-values. Each value is stored in this field with the format :

zimlet_name:property_name:property_value

10119metux wrote:
* that SOAP call will protect specific properties that may not be changed by the user.



Probably more like the soap request can only handle a defined list of properties.
10119metux wrote:
By the way: do those additional properties easily survive an upgrade ?

(you know, LDAP schemata tend to be incompatible between different

ZCS versions and the update process handles the conversion).


Never had any problems with the field for zimlet user properties.

So yes, it can easily survive an upgrade.

Welcoming script

Posted: Wed Mar 07, 2012 8:16 am
by 10119metux
Sounds good.
Seems our previous way of storing that information in an separate

mysql table was quite hackish. In future, we'll have to find a solution

to handle user movals anyways, so perhaps we can cooperate and

develop a more generic zimlet using your approach that also satisfies

our needs.

Welcoming script

Posted: Tue Mar 20, 2012 4:25 am
by tdesorbaix
I corrected a bit my example and updated the attachment.

You can just use it, modify the title and the put the HTML you want in the body of the dialog box.

Is there anything else to do? :confused:

Re: Welcoming script

Posted: Wed Jun 13, 2018 6:32 am
by thonglm
tdesorbaix wrote:Here is a simple example zimlet creating a welcome message that show up only the first time the user log in.
This use a zimlet user properties (stored in LDAP) to check if this is the first time the user log in.
zimlet_welcome.zip


Hi there,

I couldn't download the zimlet_welcome.zip

Please give me the alternative link.

Many thanks.