Hi Jonathan,
We've been discussing ideas on how to implement the features you have
mentioned and are currently trying to resolve a few problems we feel we
will face. I've listed our thoughts so far below, along with any issues
we're facing. Guys please feel free to correct/add where necessary.
Bye,
Channa.
Jonathan Marsh wrote:
This topic has languished but is becoming more urgent to solve. Most
of the proposal still seems applicable though I marked some parts that
are of lower priority.
Thoughts?
0) More on user provisioning:
a. On startup, several accounts are created:
i. System. The system account is the “author” of the built-in
foundational services. The system account is of type Guest but for
security reasons no logins under System should be allowed. While an
Administrator can delete any of the foundational services, he should
not be allowed to delete the System account.
ii. WSO2 Mashup Samples. The samples account is the “author” of the
built-in foundational services. The system account is of type Guest
but for security reasons no logins under Samples should be allowed. An
Administrator can delete any of the sample services as well as the
Samples account.
iii. Administrator. A default Administrator account with admin/admin
should be provided for the user, although ideally on install or first
run we’d allow the user to replace this account with his own (e.g. I’d
like mine to be jonathan and select my own password).
The 'system' and 'samples' accounts and resources can be created in the
registry and privileges assigned to resources within these directories.
The admin account currently gets a directory in the registry with
authority being granted to the 'admin' user, so we can create an admin
level account with a name specified by the user in a similar manner.
However we may require a system account with full privileges, that is
guaranteed to retain the id/password, in order to create instances of
the secure registry, for example.
The options to make a given account 'un-deletable' and 'non-interacive'
can probably be build into the UserManager or the Registry, as those
seem to be fairly typical use cases.
1) What gets installed:
a. Mashup Server location doesn’t matter. The user can unzip it
anywhere he wants; a Windows installer can put it in “Program Files”, etc.
Feature provided by installer.
b. Replace the “/scripts” folder inside the Mashup server directory
with two folders:
i. “/system” (or “/toolkit”?) : version, storexml, digit2image; i.e.
building block services for other mashups. This directory is owned by
the System account.
ii. “/samples” : other samples intended primarily for instructional
purposes rather than for mashing further. This directory is owned by
the Samples account.
We can simply create these locations on disk and associate them with
registry locations, so that when the contents of the directory change,
the registry is updated by the deployer. Directory ownership can be
enforced when access is through the browser, but when a user accesses
objects on the local machine's disk, these ownerships will have no
effect. If we have the scripts in the associated directories when the
server is initially unzipped or installed, the deployer will make sure
they are populated in the registry, so permissions will also be applied
on these resources.
c. Each of the above folders is a virtual directory, with mashups
available from the urls http://<domain>:7762/system/<mashup
<http://%3cdomain%3e:7762/system/%3cmashup>> and
http://<domain>:7762/samples/<mashup
<http://%3cdomain%3e:7762/samples/%3cmashup>> respectively.
The virtual directory can simply be a location where the deployer will
poll for scripts to deploy/update. However, since each mashup is
essentially just a service to axis2, it will make the service available
at /services/<mashup>. Since it is not possible to have a service name
with a slash (/), and axis2 currently does not have a concept of a
service hierarchy, we will have to come up with some namespace mechanism
to differentiate between two services with the same service name
(channa/sudoku and jonathan/sudoku).
d. Provisioning
i. (Second priority) Only localhost access to the console is permitted
until an Administrator username/password is provided by the user.
Localhost access is under Administrator privileges until an
Administrator account is created. (Will this conflict with appliance
installations?)
ii. First run (or installer config) gives the user an opportunity to
select an Administrator user name and password and location of an
initial virtual directory.
iii. (Second priority) Meaningful platform-specific values are
pre-populated for the above (where possible). For Windows Vista,
perhaps the suggested user name that corresponds to the currently
logged in user, and the initial virtual directory
C:/Users/<username>/Documents/mashups.
iv. Provide a well-known Guests directory (platform-specific?) which
will contain virtual directories associated with Guests. Should we put
System and Samples here? Which is more important, stability of these
mashups or the ability to update them? What if the user deleted them –
would we restore them?
The deployer's polling mechanism would initially be one way; it will
identify new scripts on disk, not missing ones that exist in the
registry, so restoration would not happen.
e. (Second priority) Provide a deterministic ordering for virtual
directories (in lieu of a more granular mechanism for tracking
dependencies between services)
i. Initially, the “/system” directory loads first so that other
services can import it’s artifacts (primarily stubs) safely (including
/samples relying on /system).
f. Administrator username/password, virtual directories, and any other
user preference information must be persisted so they are protected
against Mashup Server upgrades – e.g. local settings or preferences
file, Registry, etc.
We are thinking of the possibility of keeping the information to be
persisted across upgrades within the installing user's home directory in
a given operating system (e.g C:\Documents and Settings\<installing
user>\system or /home/<user>/system, similar to the approach taken by
maven. Ideally all virtual directories should fit into a known structure
within this root, so that the deployer would not have to recursively
search through an entire hierarchy of directories for scripts to be
deployed. Alternatively, if the option to arbitrarily locate virtual
directories is required, the deployer can be provided a list of
directories to be polled, with an entry being added to this list each
time a new virtual directory is configured.
2) How the user can configure it:
a. Support two classes of users – Administrators and Guests
i. Administrator. Show these capabilities on the profile page for an
Admin user.
1. add or delete Administrators or Guests.
2. add or delete virtual directories.
3. enable or disable Guest access.
All above options can be conditionally displayed/hidden using the UI, in
addition to the role based restriction that are applied by the registry
and user manager.
4. disable Administrator rights on localhost (require an admin
username password to act as Administrator)
ii. Guest
1. goes through a self-registration process (email or cardspace
verification) and receives a single virtual directory with his
username in the Guests directory. E.g. user “fred” gets the virtual
directory <platform-specific-root>/guests/fred, and the url
http://<domain>:7762/fred/mashup1.
b. Console adapts to the tasks available and information visible to
each class of user.
Again, UI can be conditioned.
c. (Second priority) Allow an Administrator to specify the “virtual
name” associated with a virtual directory. This name would appear in
URLs as the root path, and may (but typically wouldn’t) differ from
the folder name.
d. Enforce uniqueness of user account names.
Feature provided by user manager.
e. Enforce uniqueness of virtual directory names across all users. For
instance, a Guest can’t choose a username that is already in use as an
Administrator’s virtual directory, because that username doubles as a
virtual directory name.
f. (Second priority) Allow the order of virtual directories associated
with a particular Administrator to be configured, so that such a user
can define his own “toolkit” virtual directory upon which other
directories may safely depend.
*Jonathan Marsh* - http://www.wso2.com -
http://auburnmarshes.spaces.live.com
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Jonathan Marsh
*Sent:* Wednesday, October 24, 2007 2:46 PM
*To:* [email protected]
*Subject:* [mashup-dev] Some thoughts on the scripts folder, paths,
and urls
We have a number of bugs related to the virtual directory system for
mashups
MASHUP-6: Need virtual directory system
MASHUP-31: Generate clean EPR’s replicating the directory structure
for the deployed mashups
MASHUP-59: Provide unique targetNamespace bases for registered users?
MASHUP-119: Consider separating services in UI into “My services” and
“Toolkit”
MASHUP-329: Consider ways to upgrade without losing mashups
Some of the implications of these issues and our current design are:
1) Need to enable a user to keep mashups in a place separate from the
mashup installation. For instance, on Windows the mashup server
application itself would normally go into C:/Program Files, while the
mashups themselves would be most usefully stored in a particular users
Documents directory C:/Users/Jonathan/Documents/mashups. The placement
of the “scripts” folder allows a user to find it easily, include it in
indexing and backups, secure it against other users, upgrade the
mashup server without affecting scripts, etc.
2) There is a disconnect between the current directory structure
“/scripts/mymashup” and the urls “/services/mymashup”.
3) To support a community environment we need to release the
restriction on global mashup name uniqueness, although global username
uniqueness is reasonable.
4) There are platform integration issues here. For instance, can a
single Windows user have multiple Mashup users, or is there a 1-1
correspondence?
5) Built-in services and samples should be in a separate space than
user mashups – for instance an upgrade of the application should
upgrade the built-in services and samples.
6) As we move toward more of a tagging and search User Interface,
multiple directory levels with active mashups becomes loses
simplicity. Especially because the URLs don’t precisely mimic the
directory structure (e.g. inside www, http:location paths, etc.)
7) The differences between a community environment (where there is an
explicit registration process and reasonable per-user restrictions)
and a workstation install (where there is an implied user and perhaps
multiple virtual directories per user) are substantial. A one-size
approach for these scenarios is not likely to be optimum for either
user group, but perhaps we can provide a union of capabilities that
smoothly transitions from a single-user environment (e.g. no password
required for localhost access) to an installation which primarily
supports mashups from internet users.
A viable approach seems to be to keep the hierarchy to two levels: a
folder (like today’s “/scripts”) can contain a set of mashups, but we
don’t look farther down the tree, but allow a user to designate a
folder elsewhere in the file system as a virtual directory containing
mashups.
Possible detail for the workstation case:
3) What gets installed:
a. Mashup server location doesn’t matter. The user can unzip it
anywhere he wants; a Windows installer can put it in “Program Files”, etc.
b. Replace the “/scripts” folder inside the Mashup server directory
with two folders:
i. “/system” (or “/toolkit”?) : version, storexml, digit2image; i.e.
building block services for other mashups
ii. “/samples” : other samples intended primarily for instructional
purposes rather than for mashing further
c. Each of the above folders is a virtual directory, with mashups
available from the urls http://<domain>:7762/system/<mashup
<http://%3cdomain%3e:7762/system/%3cmashup>> and
http://<domain>:7762/samples/<mashup
<http://%3cdomain%3e:7762/samples/%3cmashup>> respectively.
d. Provisioning
i. Only localhost access to the console is permitted until an
Administrator username/password is provided by the user. Localhost
access is under Administrator privileges until an Administrator
account is created. (Will this conflict with appliance installations?)
ii. First run (or installer config) gives the user an opportunity to
select an Administrator user name and password and location of an
initial virtual directory.
iii. Meaningful platform-specific values are pre-populated for the
above (where possible). For Windows Vista, perhaps the suggested user
name that corresponds to the currently logged in user, and the initial
virtual directory C:/Users/<username>/Documents/mashups.
iv. Provide a well-known Guests directory (platform-specific?) which
will contain virtual directories associated with Guests.
e. Provide a deterministic ordering for virtual directories (in lieu
of a more granular mechanism for tracking dependencies between services)
i. Initially, the “/system” directory loads first so that other
services can import it’s artifacts (primarily stubs) safely (including
/samples relying on /system).
f. Administrator username/password, virtual directories, and any other
user preference information must be persisted so they are protected
against Mashup Server upgrades – e.g. local settings or preferences
file, Registry, etc.
4) How the user can configure it:
a. Support two classes of users – Administrators and Guests
i. Administrator
1. add or delete Administrators or Guests
2. add or delete virtual directories
3. enable or disable Guest access
4. disable Administrator rights on localhost (require an admin
username password to act as Administrator)
ii. Guests
1. goes through a self-registration process (email or cardspace
verification) and receives a single virtual directory with his
username in the Guests directory. E.g. user “fred” gets the virtual
directory <platform-specific-root>/guests/fred, and the url
http://<domain>:7762/fred/mashup1.
b. Console adapts to the tasks available and information visible to
each class of user.
c. Allow an Administrator to specify the “virtual name” associated
with a virtual directory. This name would appear in URLs as the root
path, and may (but typically wouldn’t) differ from the folder name.
d. Enforce uniqueness of user account names.
e. Enforce uniqueness of virtual directory names across all users. For
instance, a Guest can’t choose a username that is already in use as an
Administrator’s virtual directory, because that username doubles as a
virtual directory name.
f. Allow the order of virtual directories associated with a particular
Administrator to be configured, so that such a user can define his own
“toolkit” virtual directory upon which other directories may safely
depend.
Any comments before I flesh this out even further?
*Jonathan Marsh* - http://www.wso2.com -
http://auburnmarshes.spaces.live.com
------------------------------------------------------------------------
_______________________________________________
Mashup-dev mailing list
[email protected]
http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.16.12/1163 - Release Date: 12/1/2007 12:05 PM
--
********************************************
Channa Gunawardena
Technical Lead, WSO2 Inc.
channa at wso2.com; Mobile: +94 71 306 2722
"Oxygenating the Web Service Platform."
_______________________________________________
Mashup-dev mailing list
[email protected]
http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
