egroupware_official/phpgwapi/doc/vfs/vfs-6.html

132 lines
5.2 KiB
HTML
Raw Normal View History

2001-06-20 10:16:13 +02:00
<!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>
2001-06-23 10:30:14 +02:00
<LINK HREF="vfs-7.html" REL=next>
2001-06-20 10:16:13 +02:00
<LINK HREF="vfs-5.html" REL=previous>
<LINK HREF="vfs.html#toc6" REL=contents>
</HEAD>
<BODY>
2001-06-23 10:30:14 +02:00
<A HREF="vfs-7.html">Next</A>
2001-06-20 10:16:13 +02:00
<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-&gt;vfs-&gt;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-&gt;accounts-&gt;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 (&quot;+^$fakebase\/(.*)(\/|$)+U&quot;, $path, $matches)) &amp;&amp; $matches[1] != $account_lid)
{
$phpgw-&gt;vfs-&gt;working_id = $phpgw-&gt;accounts-&gt;name2id ($matches[1]);
reset ($memberships);
while (list ($num, $group_array) = each ($memberships))
{
if ($matches[1] == $group_array[&quot;account_name&quot;])
{
$group_ok = 1;
break;
}
}
if (!$group_ok)
{
echo $phpgw-&gt;common-&gt;error_list (array (&quot;You do not have access to group/directory $matches[1]&quot;));
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 -&gt; actual):</P>
<P>
<UL>
<LI>copy -&gt; cp</LI>
<LI>move -&gt; rm</LI>
<LI>delete -&gt; rm</LI>
<LI>dir -&gt; 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 &quot;/home&quot; as the fake base directory,
even though the user never saw it. With the new system, crafty administrators
may wish to change &quot;/home&quot; to something else, say &quot;/users&quot;
or &quot;/public_html&quot;. The fake base directory name is stored in $phpgw-&gt;vfs-&gt;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-&gt;vfs-&gt;fakebase instead</EM>.
I suggest setting $fakebase = $phpgw-&gt;vfs-&gt;fakebase; right
off the bat to keep things neater.</P>
<HR>
2001-06-23 10:30:14 +02:00
<A HREF="vfs-7.html">Next</A>
2001-06-20 10:16:13 +02:00
<A HREF="vfs-5.html">Previous</A>
<A HREF="vfs.html#toc6">Contents</A>
</BODY>
</HTML>