forked from extern/egroupware
131 lines
5.1 KiB
HTML
131 lines
5.1 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
||
|
<HTML>
|
||
|
<HEAD>
|
||
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.7.4">
|
||
|
<TITLE>phpgwapi - VFS Class: Notes</TITLE>
|
||
|
<LINK HREF="vfs-5.html" REL=previous>
|
||
|
<LINK HREF="vfs.html#toc6" REL=contents>
|
||
|
</HEAD>
|
||
|
<BODY>
|
||
|
Next
|
||
|
<A HREF="vfs-5.html">Previous</A>
|
||
|
<A HREF="vfs.html#toc6">Contents</A>
|
||
|
<HR>
|
||
|
<H2><A NAME="sec:notes"></A> <A NAME="s6">6.</A> <A HREF="vfs.html#toc6">Notes</A></H2>
|
||
|
|
||
|
<H2><A NAME="sec:database"></A> <A NAME="ss6.1">6.1</A> <A HREF="vfs.html#toc6.1">Database</A>
|
||
|
</H2>
|
||
|
|
||
|
<P>Data about the files and directories within the virtual root is kept in
|
||
|
the SQL database. Currently, this information includes:</P>
|
||
|
<P>
|
||
|
<UL>
|
||
|
<LI>File ID (used internally, primary key for table)</LI>
|
||
|
<LI>Owner ID (phpGW account_id)</LI>
|
||
|
<LI>Created by ID (phpGW account_id)</LI>
|
||
|
<LI>Modified by ID (phpGW account_id)</LI>
|
||
|
<LI>Created (date)</LI>
|
||
|
<LI>Modified (date)</LI>
|
||
|
<LI>Size (bytes)</LI>
|
||
|
<LI>MIME type</LI>
|
||
|
<LI>Deleteable (Y/N/Other?)</LI>
|
||
|
<LI>Comment</LI>
|
||
|
<LI>App (appname of application that created the file)</LI>
|
||
|
<LI>Directory (directory the file or directory is in)</LI>
|
||
|
<LI>Name (name of file or directory)</LI>
|
||
|
</UL>
|
||
|
</P>
|
||
|
<P>The internal names of these (the database column names) are stored in the
|
||
|
$phpgw->vfs->attributes array, which is useful for loops, and
|
||
|
is guaranteed to be up-to-date.</P>
|
||
|
|
||
|
|
||
|
<P>Note that no information is kept about files outside the virtual root.
|
||
|
If a file is moved outside, all records of it are delete from the database.
|
||
|
If a file is moved into the virtual root, some information, specifically MIME-type,
|
||
|
is not stored in the database. The vital information has defaults: owner is
|
||
|
based on where the file is being stored; size is correctly read; deleteable
|
||
|
is set to Y.</P>
|
||
|
<H2><A NAME="sec:acl_support"></A> <A NAME="ss6.2">6.2</A> <A HREF="vfs.html#toc6.2">ACL support</A>
|
||
|
</H2>
|
||
|
|
||
|
<P>Because of the many different ways the VFS can be used, complete ACL support
|
||
|
is not built in. There is a bit of access control built in, just because of
|
||
|
the way database queries are made. However, that is a discussion beyond the
|
||
|
scope of this document. Full ACL support may be added at a later time. For
|
||
|
now, it is fairly easy to add basic access control to your application by matching
|
||
|
path expressions. The VFS always follows the same naming convention of $fakebase/userorgroup.
|
||
|
So if you need to check if a user has access to $fakebase/whatever/dir/file,
|
||
|
you need only know if they their username is 'whatever' or if they belong to
|
||
|
the group 'whatever', and that the group has access to your application. Here
|
||
|
is an example from PHPWebHosting:</P>
|
||
|
<P>
|
||
|
<PRE>
|
||
|
###
|
||
|
# First we get their memberships
|
||
|
###
|
||
|
|
||
|
$memberships = $phpgw->accounts->memberships ($account_id);
|
||
|
|
||
|
###
|
||
|
# We determine if they're in their home directory or a group's directory
|
||
|
# If they request a group's directory, we ensure they have access to the group,
|
||
|
# and the group has access to the app
|
||
|
###
|
||
|
|
||
|
if ((preg_match ("+^$fakebase\/(.*)(\/|$)+U", $path, $matches)) && $matches[1] != $account_lid)
|
||
|
{
|
||
|
$phpgw->vfs->working_id = $phpgw->accounts->name2id ($matches[1]);
|
||
|
reset ($memberships);
|
||
|
while (list ($num, $group_array) = each ($memberships))
|
||
|
{
|
||
|
if ($matches[1] == $group_array["account_name"])
|
||
|
{
|
||
|
$group_ok = 1;
|
||
|
break;
|
||
|
}
|
||
|
}
|
||
|
if (!$group_ok)
|
||
|
{
|
||
|
echo $phpgw->common->error_list (array ("You do not have access to group/directory $matches[1]"));
|
||
|
exit;
|
||
|
}
|
||
|
}
|
||
|
</PRE>
|
||
|
</P>
|
||
|
<P>You should also check if the group has access to your appilcation.</P>
|
||
|
<H2><A NAME="sec:function_aliases"></A> <A NAME="ss6.3">6.3</A> <A HREF="vfs.html#toc6.3">Function aliases</A>
|
||
|
</H2>
|
||
|
|
||
|
<P>You might have noticed there are some functions that just pass the arguments
|
||
|
on to other functions. These are provided in part because of legacy and in
|
||
|
part for convenience. You can use either. Here is the list (alias -> actual):</P>
|
||
|
<P>
|
||
|
<UL>
|
||
|
<LI>copy -> cp</LI>
|
||
|
<LI>move -> rm</LI>
|
||
|
<LI>delete -> rm</LI>
|
||
|
<LI>dir -> ls</LI>
|
||
|
</UL>
|
||
|
</P>
|
||
|
<H2><A NAME="sec:fakebase"></A> <A NAME="ss6.4">6.4</A> <A HREF="vfs.html#toc6.4">Fakebase directory (changing /home)</A>
|
||
|
</H2>
|
||
|
|
||
|
<P>The old VFS was hard-coded to use "/home" as the fake base directory,
|
||
|
even though the user never saw it. With the new system, crafty administrators
|
||
|
may wish to change "/home" to something else, say "/users"
|
||
|
or "/public_html". The fake base directory name is stored in $phpgw->vfs->fakebase,
|
||
|
and changing it will transparently change it throughout the VFS and all applications.
|
||
|
However, this must be done <EM>before</EM> any data is in the VFS database. If you wish
|
||
|
to change it afterwords, you'll have to manually update the database, replacing
|
||
|
the old value with the new value. <EM>Application programmers need to recognize
|
||
|
that /home is not absolute, and use $phpgw->vfs->fakebase instead</EM>.
|
||
|
I suggest setting $fakebase = $phpgw->vfs->fakebase; right
|
||
|
off the bat to keep things neater.</P>
|
||
|
<HR>
|
||
|
Next
|
||
|
<A HREF="vfs-5.html">Previous</A>
|
||
|
<A HREF="vfs.html#toc6">Contents</A>
|
||
|
</BODY>
|
||
|
</HTML>
|