Welcoming script

Have a great idea for extending Zimbra? Share ideas, ask questions, contribute, and get feedback.
10119metux
Advanced member
Advanced member
Posts: 75
Joined: Sat Sep 13, 2014 2:29 am

Welcoming script

Postby 10119metux » Thu Mar 01, 2012 10:20 am

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.


tdesorbaix
Outstanding Member
Outstanding Member
Posts: 366
Joined: Fri Sep 12, 2014 10:31 pm

Welcoming script

Postby tdesorbaix » Thu Mar 01, 2012 11:08 am

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.
10119metux
Advanced member
Advanced member
Posts: 75
Joined: Sat Sep 13, 2014 2:29 am

Welcoming script

Postby 10119metux » Thu Mar 01, 2012 11:20 am

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 ?
tdesorbaix
Outstanding Member
Outstanding Member
Posts: 366
Joined: Fri Sep 12, 2014 10:31 pm

Welcoming script

Postby tdesorbaix » Fri Mar 02, 2012 3:21 am

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.
10119metux
Advanced member
Advanced member
Posts: 75
Joined: Sat Sep 13, 2014 2:29 am

Welcoming script

Postby 10119metux » Fri Mar 02, 2012 11:39 am

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).
tdesorbaix
Outstanding Member
Outstanding Member
Posts: 366
Joined: Fri Sep 12, 2014 10:31 pm

Welcoming script

Postby tdesorbaix » Mon Mar 05, 2012 4:28 am

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.
10119metux
Advanced member
Advanced member
Posts: 75
Joined: Sat Sep 13, 2014 2:29 am

Welcoming script

Postby 10119metux » Wed Mar 07, 2012 8:16 am

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.
tdesorbaix
Outstanding Member
Outstanding Member
Posts: 366
Joined: Fri Sep 12, 2014 10:31 pm

Welcoming script

Postby tdesorbaix » Tue Mar 20, 2012 4:25 am

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:
thonglm
Posts: 12
Joined: Mon Aug 29, 2016 12:54 pm

Re: Welcoming script

Postby thonglm » Wed Jun 13, 2018 6:32 am

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.

Return to “Developers”

Who is online

Users browsing this forum: No registered users and 8 guests