1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
in order to install yacutia pages:
1. create symlink "yacutia" into http server root catalog from binsrc/yacutia directory.
2. create symlink "vspx" into http server root catalog from binsrc/vspx directory.
3. run yacutia/yac.sql, yacutia/yacutia.isql scripts.
4. run vspx/vspx_vhost.sql, vspx/vspx_demo_init.sql, vspx/browser/admin_dav_browser.sql scripts.
In order to install inifile properties editor, you need:
1. copy inifile.xml file into the same directory, where .ini file is.
2. Be sure the directory binsrc/yacutia is linked on top of the http server directory under the 'yacutia' name.
In case you link it under another name, do modify yacutia/yacutia.isql script (second argument of create_inifile_page
function).
3. In .ini file do define the full path on inifile.xml file location for DirAllowed parameter.
4. Pages are ready to be used;
Note - at present time the initializing data are being stored into the same directory, where .ini file is.
but since the editor is not using yet, the data are being stored into file *.ini__
Start page name is main_tabs.vspx.
The pages access restriction mechanism.
There is few ways to manage the pages access.
First and most important is the checking of the user id.
Any yacutia page, built with yacutia_style.xsl, using VM macros allows to check user's permission to access
given page.
For the element vm:pagewrapper can be specified attribute @owner.
in case this attribute is omitted, only DBA can access for given page.
Rest users can access to this page, if and only if the value of this attribute
holds the role name, which is granted to given user. The stored procedure check_grants( in user_name, in role_name)
performs the checking of access permission and returns 1 if access is permitted.
The code for mentioned feature is implemented into <v:after-data-bind> event handler for <v:login> component.
If given user has no permission to access any page, the main_tabs.vspx page will be redirected.
Therefore any yacutia page has the access checking mechanism embedded into page code.
The code is as following:
<v:after-data-bind>
<![CDATA[
if (self.vc_authenticated) {
set_user_id (connection_get ('vspx_user'), 0);
if (self.page_owner <> null and check_grants(connection_get ('vspx_user'), self.page_owner) = 0 ) {
http_request_status ('HTTP/1.1 302 Found');
http_header (sprintf ('Location: %s?sid=%s&realm=%s\r\n', 'main_tabs.vspx', self.sid, self.realm));
}
}
]]>
</v:after-data-bind>
To make this mechanism of page access restriction more clear - read source code.
Next way is to manage the ufl_active variable of the <vm:url> and <v:button @type='image'> components.
they have attribute @allowed, which holds the role name. if the role is granted to given user (or user is DBA),
that components will be active, otherwise - won't.
Yacutia pages
At present time the following pages are done :
By Vladimir Kaluzhny:
1. Accounts Management pages.
2. Roles management pages.
3. Privileges management.
4. XSLT page.
5. XQuery execution pages.
6. Systems parameters editor
Accounts Management pages.
start url: accounts.vspx
Account create/modify page:
account_create.vspx
Account remove page:
account_remove.vspx
Description of accounts.vspx page.
On the top of the page, right of the title, there is reference on new account creation page- "Create New Account";
Then are following filter and list of the filtered accounts.
Filter consist from:
1.List of the possible rules for filter applying
2. text of the filter value
3. Button "Filter" to perform the filtering
4. Button Reset to reset filter into initial state.
The list of accounts consist from the name of the account, description of it and "Edit" & "Delete" references for each
record of the accounts list.
Account Create/Modify Dialog.
Dialog consist from the following number controls:
1. Real name - description of the user
2. Login name
3. Two boxes to enter the password
4. Default group
5. Additional groups
6. Default qualifier
7. Can this user authenticate via ODBC?
8. Can this user authenticate via HTTP?
9. Default Permissions
10.Create Repository Collection?
11.Repository Collection Path
12.Generate Key Pair?
13.Key Passphrase
14.Create Local Mailbox?
15.Size
Buttons: Cancel, Reset, Save
Roles management pages.
start page- roles.vspx
Description of the roles page.
On the right of dialog title "Group" there is reference "Create New Group"
Then below there exist list of the roles.
The list of roles consist from the name of the role, description of it and "Edit" & "Delete" references for each
record of the roles list.
Create/Modify role.
This dialog appears on the top of the roles list and allows to specify
1. The name of the role.
2. Description of the role
3. Grant the new role to the existing ones.
User must specify:
1. role name.
2. Role description
then user can specify the users/roles to which this new will be granted.
For this user have to:
1. Select the desired items form list of intended members.
(in order to lower the list length, user can specify -
if the user or/and group names have to be included into list.
"Reload" button allows to reload the intended members list)
2. Press button "Grant" in order to move the previously selected items into
the "Granted to" list.
3. if user wish, it can Revoke the items. it should select the items into
the "Granted to" list.
Privileges management.
XSLT perform page.
XQuery execution pages.
these pages are implemented on Wizard manner.
First screen is to specify data context for xquery execution.
the possible contexts are: DAV repository, DB table, URL (on HTTP or FTP resource), no context
Second screen depends for kind of context.
1. if the context is DAV repository, this screen is to specify the DAV located file.
2. if the context is Table, this screen has three parts
2.1 to specify the table. there is possibility to specify desired qualifier and after this specify the table name
2.2 to specify the desired Key column and Value column
2.3 to specify the desired value of key column
3. if the context is Internet resource URL, this screen is to specify URL value
Third Screen is to specify:
1. xquery expression text
2. Apply XSLT on taken result or not.
3. XSLT file reference
4. Output to: Screen or DAV Repository.
5. Root document node
Fourth screen is to specify the DAV storage parameters, in case "Output to" designated to DAV Repository.
1. Store into - the path to store file in.
2. Permission
3. The ways to create the xml file:
3.1 just persist the xml file
3.2 Create XML in Real time. the updating interval should be specified. default is 10 min.
3.3 Create the XML Template on given xquery.
Fifth screen is the result of xquery execution. from this page user can go onto first screen again.
|
