From: Thomas W. <tho...@gm...> - 2009-11-25 23:51:31
|
Dear all, Bellow is my vision about admin RESTful URLs. We should try to pass the parameters as parts of the URL if we can distinguish the paramemeters easily : {application}/{module}/{object-type}/{action}/{single-parameter} {application}/{module}/{object-type}/{action}/{id}/{old-value}/{new-value} *A. Server Configuration.* Module name: configuration.xql. We can have the following types of updates: A.1 whole file: HTTP PUT /admin/configuration/conf.xml/replace A.2 an XML fragment: HTTP PUT /admin/configuration/conf.xml/node-replace/db-connection/pool A.3 an element or attribute value: the last part of the URL is the new value. GET /admin/configuration/conf.xml/update-value/ db-connection/pool/@cacheSize/128M A.4 Configuration save/restore GET /admin/configuration/conf.xml/save?to=c:/config-data GET /admin/configuration/conf.xml/load?from=c:/config-data * B. Server information (view only).* Module name: state.xql /admin/state/status /admin/state/statistics /admin/state/performance-monitor /admin/state/statistics/ profiling * C. Job management.* Module name: jobs.xql /admin/jobs/list-running-jobs /admin/jobs/list-scheduled-jobs /admin/jobs/kill/job-id /admin/jobs/set-priority/job-id/priority *D. Admin actions.* Module name: actions.xql /admin/do/restart /admin/do/reload /admin/do/shutdown /admin/do/backup/{root-collection-of-the backup}[?to=c:/backups] /admin/do/restore/{root-collection-of-the backup}?from=c:/backups/backup-file.zip /admin/do/reindex/{collection-URI} *E. Security, User and Group Management.* Module name: sequrity.xql /admin/security/user/add/new-user-id/password/{home-collection} /admin/security/user/delete/user-id /admin/security/user/add-to-group/user-id-to-add /admin-users-group /admin/security/user/rename/old-user-name/new-user-name /admin/security/group/add/group-name/group-description /admin/security/group/rename/old-group-name/new-group-name /admin/security/group/add-user/admin-users-group/user-id-to-add /admin/security/list-groups?page=x&page-size=xx /admin/security/list-users?page=x&page-size=xx /admin/security/global/default-access/{permissions} /admin/security/collection/permissions-set/{URI}/{ permissions } /admin/security/resource/permissions-set/{URI}/{ permissions } /admin/security/resource/owner-set/{URI}/{new-owner} /admin/security/resource/group-set/{URI}/{ new-group } *) User bulk operations - I do not have a clear idea jet *) Bulk(recursive) security operations - I do not have a clear idea jet * F. Data browser.* Module name browser.xql F.1. browse collections/resources. To get all set page-size to 0, sort is optional: /admin/browser/list-sub-collections/{collection-URI}/{page}/{page-size}?sort-by=[name|date|size] /admin/browser/list-resources/{collection-URI}/{page}/{page-size}?sort-by=[name|date|size] F.2 collections/resources operations: /admin/browser/collection/move/db/collection-abc?to=/db/new-parent-collection /admin/browser/resource/move/db/collection-abc/data.xml?to=/db/new-parent-collection /admin/browser/collection/clone/db/collection-abc?to=/db/new-parent-collection /admin/browser/resource/clone/db/collection-abc/data.xml?to=/db/new-parent-collection Note: clone copies all permitions as well /admin/browser/collection/backup/db/collection-abc?to=/db/new-parent-collection /admin/browser/collection/restore/db/collection-abc?from=c:/backups/backup.zip /admin/browser/collection/export/db/collection-abc/data.xml?to=c:/exported-xml-data /admin/browser/collection/import/db/collection-abc/data.xml?from=c:/exported-xml-data /admin/browser/resource/import/db/collection-abc?from=c:/exported-xml-data/data.xml /admin/browser/resource/export/db/collection-abc/data.xml?to=c:/exported-xml-data It is important to put all code that perform the actions into the module files and every specific user interface implementation like XForms, AJAX, plane HTML or iPhone will include the module to call the action first and later return whatever specific implementation content is needed. Module files will be in application collection/directory. All files from a specifc user interface implementation will be in a single sub-collection under admin, like /admin/XForms, /admin/iPhone or /admin/jQuery. A controller.xql in admin collection/directory will translate the URLs into XQuery URI and parameters. The preferred implementation will be added as a prefix to the XQuery URI. Any comments or questions? Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 |
From: Dmitriy S. <sha...@gm...> - 2009-11-26 02:48:21
|
On Wed, 2009-11-25 at 23:50 +0000, Thomas White wrote: > B. Server information (view only). Module name: state.xql Will we have any history data? example: logs view. How to handle it? from - to as one parameter? ( {application}/{module}/{object-type}/{action}/{single-parameter} ) -- Cheers, Dmitriy Shabanov |
From: Thomas W. <tho...@gm...> - 2009-11-26 10:16:20
|
Dmitriy, I guess we need pagination for the log files as well. Then the URLs will be: /admin/logs/list-all /admin/logs/exist.log/{page-size}/{page-number} Dan, How these URLs ideas fit with your point of view? Regards, Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 2009/11/26 Dmitriy Shabanov <sha...@gm...> > On Wed, 2009-11-25 at 23:50 +0000, Thomas White wrote: > > B. Server information (view only). Module name: state.xql > > Will we have any history data? example: logs view. > > How to handle it? from - to as one parameter? > ( {application}/{module}/{object-type}/{action}/{single-parameter} ) > > -- > Cheers, > > Dmitriy Shabanov > > |
From: Dannes W. <di...@ex...> - 2009-11-26 11:18:44
|
Hi, On Thu, Nov 26, 2009 at 11:15 AM, Thomas White <tho...@gm...> wrote: > I guess we need pagination for the log files as well. Then the URLs will be: > /admin/logs/list-all > /admin/logs/exist.log/{page-size}/{page-number} > > Dan, > How these URLs ideas fit with your point of view? please, no.. make a design that fits the logging, do not change the logging to fit the new interface..... logfiles do not have pages, log files are changed after every x mb etc. D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Dannes W. <di...@ex...> - 2009-11-26 11:19:33
|
hi, On Thu, Nov 26, 2009 at 12:18 PM, Dannes Wessels <di...@ex...> wrote: > logfiles do not have pages, log files are changed after every x mb etc. think of a never endig, though formatted, stream. D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Dmitriy S. <sha...@gm...> - 2009-11-26 11:30:14
|
On Thu, 2009-11-26 at 12:19 +0100, Dannes Wessels wrote: > hi, > > On Thu, Nov 26, 2009 at 12:18 PM, Dannes Wessels <di...@ex...> wrote: > > logfiles do not have pages, log files are changed after every x mb etc. > > think of a never endig, though formatted, stream. + filtered by parameter or several -- Cheers, Dmitriy Shabanov |
From: Thomas W. <tho...@gm...> - 2009-11-26 11:35:08
|
Dannes, This URL is to display the log in a browser in reasanable chunks. I do think it will be practical to just dump 60,000 lines the browser. Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 2009/11/26 Dannes Wessels <di...@ex...> > Hi, > > > On Thu, Nov 26, 2009 at 11:15 AM, Thomas White <tho...@gm...> > wrote: > > I guess we need pagination for the log files as well. Then the URLs will > be: > > /admin/logs/list-all > > /admin/logs/exist.log/{page-size}/{page-number} > > > > Dan, > > How these URLs ideas fit with your point of view? > > please, no.. make a design that fits the logging, do not change the > logging to fit the new interface..... > > logfiles do not have pages, log files are changed after every x mb etc. > > D. > > -- > eXist-db Native XML Database - http://exist-db.org > Join us on linked-in: http://www.linkedin.com/groups?gid=35624 > |
From: Dmitriy S. <sha...@gm...> - 2009-11-26 11:43:23
|
On Thu, 2009-11-26 at 11:34 +0000, Thomas White wrote: > Dannes, > > This URL is to display the log in a browser in reasanable chunks. I do > think it will be practical to just dump 60,000 lines the browser. We need a log stream, not a page. When log's page open it should receive all log staff, till it be close (page). aka "tail -f eXist.log", but web -- Cheers, Dmitriy Shabanov |
From: Wolfgang M. <wol...@ex...> - 2009-11-26 11:56:58
|
> We need a log stream, not a page. When log's page open it should receive > all log staff, till it be close (page). aka "tail -f eXist.log", but web I agree a comet application would be more appropriate for viewing a log. This can be done easily with a servlet and a hidden iframe. It would help to keep the load on the server low. The log viewer does not even need to be eXist-specific. Wolfgang |
From: Dmitriy S. <sha...@gm...> - 2009-11-26 12:05:50
|
On Thu, 2009-11-26 at 12:56 +0100, Wolfgang Meier wrote: > > We need a log stream, not a page. When log's page open it should receive > > all log staff, till it be close (page). aka "tail -f eXist.log", but web > > I agree a comet application would be more appropriate for viewing a > log. This can be done easily with a servlet and a hidden iframe. It > would help to keep the load on the server low. The log viewer does not > even need to be eXist-specific. I thinking about log analyze (tool). Missing it :) "keep the load on the server low" - rerouting shouldn't make this problem (hope) -- Cheers, Dmitriy Shabanov |
From: Thomas W. <tho...@gm...> - 2009-11-26 12:42:35
|
I think I need to refine the meaning of page in this case. Dealing with large data sets always require some sort of displaying the data in chunks/parts/pages and navigating between them. How we are going to call it is not relevant. The practice has showed us many times a simple truth - sending large data down the wire is never a good idea. A log chunk could be selected by range of line number (page-size and page-number is effectively the same) or by range of timestamps. The page is a set of lines taken from the file and displayed in the browser at the moment of accessing the file. We can display say 500 lines at a time and walk up and down another 500 lines. We can event start displaying the last 500 lines if we want. That fact that this file grows it real time does not change the need of delivering the data in chunks - we just need a simple mechanism of periodically querying for data with timestamp older then the last update. Delivering the data in chunks does not necessarily mean it will be displayed as pages - the new data can be just appended on the screen. jQuery can do miracles with very little code. I agree if we have a servlet that can access the logs and deliver part of the log this will be the best. The servlet can accept the following parameters: log-file-name and one of the following: a) first-line-number, last-line-number b) page-size, page-number, c) timestamp-beginning, timestamp-end d) all-after-timestamp e) all ( bad idea! ) another method: logs-list: returns the name of the logs files, their sizes and last updated timestamp. I hope this clarification will help. Regards, Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 2009/11/26 Dmitriy Shabanov <sha...@gm...> > On Thu, 2009-11-26 at 11:34 +0000, Thomas White wrote: > > Dannes, > > > > This URL is to display the log in a browser in reasanable chunks. I do > > think it will be practical to just dump 60,000 lines the browser. > > We need a log stream, not a page. When log's page open it should receive > all log staff, till it be close (page). aka "tail -f eXist.log", but web > > -- > Cheers, > > Dmitriy Shabanov > > |
From: Dmitriy S. <sha...@gm...> - 2009-11-26 12:49:59
|
On Thu, 2009-11-26 at 12:42 +0000, Thomas White wrote: > c) timestamp-beginning, timestamp-end How to apply it to url? -- Cheers, Dmitriy Shabanov |
From: Thomas W. <tho...@gm...> - 2009-11-26 12:58:39
|
admin/logs/exist.log/line-range/fist-line/last-line admin/logs/exist.log/page/page-size/page-number admin/logs/exist.log/time-range/2009-11-23 10:37:50:703/2009-11-23 10:37:55:903 admin/logs/exist.log/all-after/2009-11-23 10:37:50:703 admin/logs/exist.log/all a) first-line-number, last-line-number b) page-size, page-number, c) timestamp-beginning, timestamp-end d) all-after-timestamp e) all ( bad idea! ) Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 2009/11/26 Dmitriy Shabanov <sha...@gm...> > On Thu, 2009-11-26 at 12:42 +0000, Thomas White wrote: > > c) timestamp-beginning, timestamp-end > > How to apply it to url? > > -- > Cheers, > > Dmitriy Shabanov > > |
From: Dmitriy S. <sha...@gm...> - 2009-11-26 13:16:17
|
To make sure I did understand: admin/logs/exist.log/line-range/fist-line/last-line logs - script exist.log - first parameter - file name line-range - second parameter - command name fist-line - first command parameter fist-line - second command parameter so, it going be {application}/{module}/{object-type}/{action}/{parameter}/{parameter} -- Cheers, Dmitriy Shabanov On Thu, 2009-11-26 at 12:58 +0000, Thomas White wrote: > admin/logs/exist.log/line-range/fist-line/last-line > admin/logs/exist.log/page/page-size/page-number > admin/logs/exist.log/time-range/2009-11-23 10:37:50:703/2009-11-23 > 10:37:55:903 > admin/logs/exist.log/all-after/2009-11-23 10:37:50:703 > admin/logs/exist.log/all > > a) first-line-number, last-line-number > b) page-size, page-number, > c) timestamp-beginning, timestamp-end > d) all-after-timestamp > e) all ( bad idea! ) > > Thomas > > ------ > > Thomas White > > Mobile:+44 7711 922 966 > Skype: thomaswhite > gTalk: thomas.0007 > Linked-In:http://www.linkedin.com/in/thomaswhite0007 > facebook: http://www.facebook.com/thomas.0007 > > > > > 2009/11/26 Dmitriy Shabanov <sha...@gm...> > On Thu, 2009-11-26 at 12:42 +0000, Thomas White wrote: > > c) timestamp-beginning, timestamp-end > > > How to apply it to url? > > -- > Cheers, > > Dmitriy Shabanov > > |
From: Dan M. <dan...@gm...> - 2009-11-27 11:26:08
|
eXcellent feedback Tomas. You have a nice holistic view of other areas of administration that I had not considered for RESTful interfaces. A few small suggestions. To be consistent with the /admin/{object}/{action} format, perhaps we could officially use "server" as a named object. So the following might be some actions on the database server: /admin/server/shutdown /admin/server/restart /admin/state/status /admin/state/statistics etc. This might be a little more precise then the label "do". I would also like to keep all the operations on collections in a single areas so that we can enable/disable collection operation buttons. So if you specify: /admin/collection The REST interface would return a list of all possible operations on a collection: Create New Index, Edit Index, Estimate Index Creation Time, Index (Reindex) Collection, Update Index, Change Owner, Change Permissions, Create New Trigger, Edit Trigger, Add Version, Move, Rename, Collection Size, Synchronize, Edit Access Policy, Upload Files, Collection Details, Delete Collection, Copy, Backup Collection, Restore Collection, Create a New Subcollection Perhaps I should refactor the collection admin database to include a single object type code list: The list of possible admin objects might include: configuration-file collection group index log-file policy resource server trigger user etc. I also would like to suggest we talk to Loren about how we might create a RESTful interface to an existing logfile analyzer like "Apache Chainsaw". See http://logging.apache.org/chainsaw Loren is an expert on logfile viewing and has already spent a great deal of time thinking about integrating Apache Chainsaw with eXist. - Dan |
From: Thomas W. <tho...@gm...> - 2009-11-27 13:58:26
|
Dan, Thank you for the feedback. I can see your preference to the REST URL is /admin/{object}/{action} I would still prefer /admin/{module}/{object}/{action} We need to think about admin work as set of activities where different people will have access to different subset of possible actions. It is an exception, usually for small projects where one person is admin and he is responsible for all admin tasks. More common case is when we have more then one administrator. If we group common activities to a module we can easily grant access to this module and these activities. Conversely if we put all actions for an object in one place /admin/{object}/{action} then it will be much more difficult or complex do define in details who can do what. We are discussing URLs here and the implementation of all actions for an object, say collection, can still be in a single module. I do not really like the idea of receiving the list of possible actions when URL is /admin/collection. To request the list of action is an action and to me it looks like /admin/{module}/collection/action-list. It can return the subset of the available actions for the context of the module combined with user credentials including groups and roles. This way we can control the access to the every action depending on who is asking I not sure about the meaning of "enable/disable collection operation". Do you mean to allow the user to perform the actions or not? This could be a case only if we think admin vs non-admin users. In real life wе may have Backup Admin, User Admin, System admin and all of them may have different subset of actions. User admin does not need to be able to shutdown the server, change configuration or access the data in any collection. I like your note about replacing 'do' with 'server' . Then we can have: /admin/administration/server/restart /admin/administration/server/reload /admin/administration/server/shutdown /admin/administration/server/backup/{root-collection-of-the backup}[?to=c:/backups] /admin/administration/server/restore/{root-collection-of-the backup}?from=c:/backups/backup-file.zip /admin/administration/server/reindex/{collection-URI} I think we need an extra parameter 'mode' that will define what will be returned - XML, JSON, HTML, XForm. About the log files viewer, I will be happy to put our heads together and come up with a simple and quick solution. I just realised - we may be talking about two different sets of URLs. I believe we are discussing an RESTful API to perform admin actions. These URLs are not the URL that a web application will have - neither the main application URL nor the application modules' URLs. The way URLs are constructed within any web application depends on many factors including the technology and even the personal preferences of the author. Application URLs should not be an object of restrictions or any hard rules. Regards, Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 2009/11/27 Dan McCreary <dan...@gm...> > eXcellent feedback Tomas. > > You have a nice holistic view of other areas of administration that I > had not considered for RESTful interfaces. > > A few small suggestions. > > To be consistent with the /admin/{object}/{action} format, perhaps we > could officially use "server" as a named object. > > So the following might be some actions on the database server: > > /admin/server/shutdown > /admin/server/restart > /admin/state/status > /admin/state/statistics > > etc. > > This might be a little more precise then the label "do". > > I would also like to keep all the operations on collections in a > single areas so that we can enable/disable collection operation > buttons. So if you specify: > > /admin/collection > > The REST interface would return a list of all possible operations on a > collection: > > Create New Index, Edit Index, Estimate Index Creation Time, Index > (Reindex) Collection, Update Index, Change Owner, Change Permissions, > Create New Trigger, Edit Trigger, Add Version, Move, Rename, > Collection Size, Synchronize, Edit Access Policy, Upload Files, > Collection Details, Delete Collection, Copy, Backup Collection, > Restore Collection, Create a New Subcollection > > Perhaps I should refactor the collection admin database to include a > single object type code list: > > The list of possible admin objects might include: > > configuration-file > collection > group > index > log-file > policy > resource > server > trigger > user > > etc. > > I also would like to suggest we talk to Loren about how we might > create a RESTful interface to an existing logfile analyzer like > "Apache Chainsaw". > > See http://logging.apache.org/chainsaw > > Loren is an expert on logfile viewing and has already spent a great > deal of time thinking about integrating Apache Chainsaw with eXist. > > - Dan > |
From: Dmitriy S. <sha...@gm...> - 2009-11-28 04:01:33
|
On Fri, 2009-11-27 at 13:33 +0000, Thomas White wrote: > Dan, > > Thank you for the feedback. > > I can see your preference to the REST URL is /admin/{object}/{action} > > I would still prefer /admin/{module}/{object}/{action} For me (as linguist :) no differences between "object" & "module". To make it flexible: /admin/{object}/{object}/{action}/{object}/{object} The parsing is quite simple: 1. analyze first "object"s till get the module. (possible to omit) 2. "action" = function 3. second "object" - the information for function That is very simple, the "action" split "object"s on "which" & "where". The parsing time should be low too. > We need to think about admin work as set of activities where different > people will have access to different subset of possible actions. It is > an exception, usually for small projects where one person is admin and > he is responsible for all admin tasks. More common case is when we > have more then one administrator. If we group common activities to a > module we can easily grant access to this module and these > activities. > > Conversely if we put all actions for an object in one > place /admin/{object}/{action} then it will be much more difficult or > complex do define in details who can do what. > > We are discussing URLs here and the implementation of all actions for > an object, say collection, can still be in a single module. > > I do not really like the idea of receiving the list of possible > actions when URL is /admin/collection. To request the list of action > is an action and to me it looks like > /admin/{module}/collection/action-list. It can return the subset of > the available actions for the context of the module combined with user > credentials including groups and roles. This way we can control the > access to the every action depending on who is asking > > I not sure about the meaning of "enable/disable collection > operation". Do you mean to allow the user to perform the actions or > not? This could be a case only if we think admin vs non-admin > users. In real life wе may have Backup Admin, User Admin, System > admin and all of them may have different subset of actions. User admin > does not need to be able to shutdown the server, change > configuration or access the data in any collection. > > I like your note about replacing 'do' with 'server' . Then we can > have: > > /admin/administration/server/restart > /admin/administration/server/reload > /admin/administration/server/shutdown > /admin/administration/server/backup/{root-collection-of-the > backup}[?to=c:/backups] > /admin/administration/server/restore/{root-collection-of-the > backup}?from=c:/backups/backup-file.zip > /admin/administration/server/reindex/{collection-URI} /admin/administration is tautology. we did definition area by "admin", why redefine it again by administration. It can be /siteN/admin/.... Your idea is based on different users usage, but "server" for system admin, "server/backup" backup admin. My view: /admin/system/restart /admin/system/reload /admin/system/shutdown /admin/backup/{root-collection-of-the-backup}[?to=c:/backups] /admin/restore/{root-collection-of-the-backup}?from=c:/backups/backup-file.zip /admin/reindex/{collection-URI} "system" -> module; "restart" -> function "backup" -> module & function If be honest, I like single "module & function" concept more that "module & functions". It's simple in developing & understanding. > I think we need an extra parameter 'mode' that will define what will > be returned - XML, JSON, HTML, XForm. > > About the log files viewer, I will be happy to put our heads together > and come up with a simple and quick solution. {action}/{object}/{object} should be ok here. /admin/log/period/eXist.log/{datetime}/{datetime} /admin/log/tail/{log-id} (funny, it can be /admin/eXist.log/period/{datetime}/{datetime} & it possible to parse & "understand"! "log" miss, because of "eXist.log" - it have single "meaning") -- Cheers, Dmitriy Shabanov PS I what to try coding, any svn? under eXist one? |
From: Thomas W. <tho...@gm...> - 2009-11-28 14:00:09
|
Dear all, It seams I forgot to mention the reasons why I introduced the idea of modules. But before I go to any details let me make a small adjustment in the terminology. The word 'module' brings associations related to implementation. What I have in my mind is the everyday use of administrative tools that usually are done by different people. Imagine a junior admin that usually adds users and groups, who accidentally shutdowns the server or even worse - deletes the main data collection. The proper word we can use to describe this perspective is *'area'*. It may help if we think about any area, almost like a job description that can be given to somebody to perform a specific set of tasks without need to have access to any other admin resources. 1) Areas cover different activities of the administration, access to which is a likely to be granted in more granular way. 2) An area comprises of set of actions that are likely to be developed and used together. 3) When we have areas, each of them will have its own controller.xql with specific way of extracting parameters. The alternative is a mile long single controller.xql for all functionalities. 4) In some cases (production db) not all admin functions are required. When we have areas, simple by deleting the directory/collection with unwanted code (or copy back when needed) the problem is solved quickly and easily. Conversely if we have a single a mile long controller.xql with all code in a single location, then we need to edit copy/paste|delete|comment/uncomment fragments in the controller, apart from the copying/deleting the code, which does not look very practical to me. 5) When we have areas of administration we deal with same objects, but from different perspective. For example a collection in the area of data browser may give us list of child resources and sub-collections, while in the area of security the actions for a collection in this context are completely different. When we implement the modules we can choose to either have a monolithic module for every object or multiple modules that cover only the actions(functions) in an single area. Because different areas are likely to be coded by different developers and we want to be able to remove some of the areas in not needed, my preference will be to have multiple module files, with names as '{object}_{area}.xqm' I agree, the area name 'administration' is not good - 'system' is much better. We need to revisit the names of areas and choose the wording that fits well. - config - state - jobs - system - I can't come up with a name for the backup & restore area. The job description is backup admin. any ideas? - data - reindex, import, export. - security - browser > /admin/log/period/eXist.log/{datetime}/{datetime} > /admin/log/tail/{log-id} > (funny, it can be /admin/eXist.log/period/{datetime}/{datetime} & it > possible to parse & "understand"! "log" miss, because of "eXist.log" - > it have single "meaning") I think the idea when we build the URL is to go from more generic to a specific, from what I am going to do, to parameters that describe how to do it. That is why I would prefer: /admin/log/eXist.log/period/{datetime}/{datetime} BTW using negative page/chink numbers, we can address the file from the end up: /admin/log/eXist.log/page/250/-1 will give us the last 250 lines of the log file. About the log files. The following sequence can allow us to navigate in a log file easily and simply with a little bit of AJAX magic, using only three methods: 1. start with the last xxx lines: /admin/log/eXist.log/page/{number-of-lines-to-get}/-1 2. Use the first timestamp in the chunk and create a link for the previous page: /admin/log/eXist.log/before/{time-stamp-of-the-first-line-in-the-chunk}/{number-of-lines-to-get} after click and receiving the new chunk of lines, insert them at the top of the screen (using AJAX), Do this step again to produce the link for the new previous page. 3. Use the last timestamp of the chunk and create a link for the next page. /admin/log/eXist.log/after/{time-stamp-of-the-last-line-in-the-chunk}/{number-of-lines-to-get} after click and receiving the new chunk of lines, insert them at the bottom of the screen (using AJAX), Do this step again to produce the link for the new next page. The link for the next page can be executed, using AJAX, every XX seconds to get the new lines appended to the log file. I hope this long post has brought more clarity about my view point of the admin RESTful URLs. Regards, Thomas |
From: Joe W. <jo...@gm...> - 2009-11-28 20:36:32
|
Thomas, > What I > have in my mind is the everyday use of administrative tools that usually are > done by different people. Imagine a junior admin that usually adds users and > groups, who accidentally shutdowns the server or even worse - deletes the > main data collection. > > The proper word we can use to describe this perspective is 'area'. It may > help if we think about any area, almost like a job description that can be > given to somebody to perform a specific set of tasks without need to have > access to any other admin resources. Your description of 'area' sounds more like what I think of as 'role' - as in RBAC, which covers all actions/resources that users are authorized to access, including admin functions like those for this admin app. Could you elaborate on the distinction, if any, between your 'area' and 'role'? How do you imagine preventing the user in your example from accessing other admin areas -- through some sort of URL-based access control, or through RBAC (which focuses on documents, collections, functions, and modules)? You also listed many ideas about isolating an area into a single directory with its own controller.xql. Most of your points up to now have been about URLs, but this gets into coding structure. Do you have ideas about ways to arrange the code so that it fits your criteria for modularity? Joe |
From: Thomas W. <tho...@gm...> - 2009-12-01 23:13:58
|
Joe, An ‘area’ is very similar to ‘role’, although an area could be created with roles or groups or whatever means the current implementation offer to allow XML resources to be read only by authorised users. The first implementation of the area access control could be the following: In every area collection, for every action we have an XML file that can be read only by the group or role authorised for this area, say ‘system-admin’ group: /admin/system/server/action-restart.xml <action> <id>restart</id> </action> /admin/system/server/ action-reload.xml <action> <id>reload</id> </action> /admin/ system /server/action-shutdown.xml <action> <id> shutdown </id> </action> The controller in this area collection loads xdb:xcollection($exist:controller)/action/id to enumerate the available actions for the current user. If the user is not member of the ‘system-admin’ group, then the list of the actions will be empty. When the requested action is in the list, then the controller will call the function for the action with the extracted parameters from the URL. The controller in the application collection will capture the calls for the missing areas collections and return ‘unavailable-action’ result. Regards, Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 2009/11/28 Joe Wicentowski <jo...@gm...> > Thomas, > > > What I > > have in my mind is the everyday use of administrative tools that usually > are > > done by different people. Imagine a junior admin that usually adds users > and > > groups, who accidentally shutdowns the server or even worse - deletes the > > main data collection. > > > > The proper word we can use to describe this perspective is 'area'. It may > > help if we think about any area, almost like a job description that can > be > > given to somebody to perform a specific set of tasks without need to have > > access to any other admin resources. > > Your description of 'area' sounds more like what I think of as 'role' > - as in RBAC, which covers all actions/resources that users are > authorized to access, including admin functions like those for this > admin app. Could you elaborate on the distinction, if any, between > your 'area' and 'role'? > > How do you imagine preventing the user in your example from accessing > other admin areas -- through some sort of URL-based access control, or > through RBAC (which focuses on documents, collections, functions, and > modules)? > > You also listed many ideas about isolating an area into a single > directory with its own controller.xql. Most of your points up to now > have been about URLs, but this gets into coding structure. Do you > have ideas about ways to arrange the code so that it fits your > criteria for modularity? > > Joe > |
From: Joe W. <jo...@gm...> - 2009-12-03 14:03:54
|
Hi Thomas, > An ‘area’ is very similar to ‘role’, although an area could be created with > roles or groups or whatever means the current implementation offer to allow > XML resources to be read only by authorised users. What you said sounds reasonable -- in that you're relying on other mechanisms (read privileges, granted through the builtin unix-style permissions or XACML) for authorization, rather than reinventing the wheel through some predetermined, hardcoded URL-based scheme. > In every area collection, for every action we have an XML file that can be > read only by the group or role authorised for this area, say ‘system-admin’ > group: > > /admin/system/server/action-restart.xml > <action> > <id>restart</id> > </action> I like the idea of action XML files for augmenting authorization, although these files needn't necessarily be stored in an area subcollection. These XML files could conceivably be stored in a single, common collection. I would say that 'area' in your proposal is merely a convenient way to group actions together into a collection so that permissions can be applied to the whole collection, rather than on a file-by-file basis. It's an internal permissions issue. I don't yet see a compelling reason why this issue should impact the URL design, in terms of requiring that 'area' be a part of the URL. In other words, it seems to me that your notion of 'area' is still an authorization concept, rather than a concept that should drive the URL or application organization. The weakness in organizing an app around preconceived notions of user groups is that authorization needs are different for just about every organization. That said, I think the most compelling claim you've made for organizing the admin section around 'area' is in that it could help the admin section be modular -- letting developers select groups of admin actions for their applications. This is a very different goal than an 'authorization' goal, and I agree that it's desirable. But I haven't seen how 'area' helps achieve that flexibility from what you've said. Is there anything you could add that would back this claim up? Could you flesh out where action-restart.xql/m would be stored relative to the main admin xquery file, and how a developer could disable this action from their app without trouble? I think the questions for everyone are: 1. Do folks think XML files that describe atomic admin 'actions' are a good way to handle authorization? If so, should the 'action' XML file be organized into pre-determined 'area' sub-collections, or should the grouping of these files be left to the individual developer? 2. Does this notion of 'area' really help the admin app stay modular? What's the best way to organize the admin app so that both groups of actions and individual actions can be turned on/off? Joe |