question about backups

Sebastian Goebel wrote:
> The only thing I would like to be added it that
storageServer move the
> backup file to target location by itself. It could be
done by htmlUI while
> it is "running", but if nobody logs in, it
would need an extra cron job to
> do that.

The problem with this solution is that the storage server
may be on a 
different computer (on a LAN, for example) than the html UI
being used. 
  So the location selected by the user may be writable by
the html UI, 
but not by the storage server.  You could test-write
('touch') the 
location before you call xxxOpen(), and display an error if
that failed.

I understand you want to eliminate the copying of a
(possibly quite) 
large file, but I don't think we can.

About 'orphaned' asynch calls: the storage server should
probably remove 
the temp files it created after some time, if nobody calls
xxxClose() on 
them.  The UIs can keep their tokens in the user prefs, and
check at 
startup whether there are any active tokens (like they do
now for edited 
playlists).  One of the 'fault' error messages returned by
the 
xxxCheck() function would then be "the token has
expired".

Ferenc

PS. why was this on core?  I moved it to dev.

> The problem with this solution is that the storage
server may be on a
> different computer (on a LAN, for example) than the
html UI being used.

No, the storageServer have to be on same host as htmlUI,
because htmlUI uses
PHP-API (include the storageServer files, direct method
calls).

Working on the UC's i came across to check permission for
them.

Currently htmlUI just check permission of action
'subjects' to allow
changing users/groups (and stationsettings, which have to
change to
group-mebership to "stationPrefs").

My proposal
Pre-defined Groups:
- stationPrefs	grant access to stationsettings
- backup		allow to create backups
- restore		allow to restore backups
- subjects 		grant access to user/group management


Such seems to be more logical than using
GreenBox::CheckPerm(), and
especially allow admins to grant permission to users by
managing their
membership.


Sebastian

Does somebody know an easy-to-use file explorer written in
PHP?

I need it to let the user choose an backup-location on the
servers
filesystem.

On Fri, 10 Mar 2006 16:34:42 +0100 Sebastian Goebel wrote:
> Does somebody know an easy-to-use file explorer written
in PHP?
> 
> I need it to let the user choose an backup-location on
the servers
> filesystem.
> 

This seems to be useful:
http://evoluted.net/archives/2005/08/directory_listi_2
.php
demo:
http://evoluted.net/stuff/


This is probably php4 only, but good:
http://wacker-welt.de
/webadmin/

-- 
Tomas Hlava
thred2head.com

At 20:51 10.03.2006, you wrote:
>This is probably php4 only, but good:
>http://wacker-welt.de
/webadmin/

yes. i love it. seriously.

Micz Flor - miczmi.cz

content and media development               http://mi.cz
--------------------------------------------------------
http://www.campware.org  
   --      http://www.suemi.de
http://www.redaktion
undalltag.de
--------------------------------------------------------

Sebastian Goebel wrote:
> Such seems to be more logical than using
GreenBox::CheckPerm(), and
> especially allow admins to grant permission to users by
managing their
> membership.

IMHO all permission checking should be done at the backend,
and by alib.
is GreenBox::CheckPerm() the alib call to check permissions?

also, elaborate permissions are not a priority for the
Freetown release..


Akos

Sure, permissions are checked by backend too. But for some
actions, the gui
should not show actions which are forbidden to perform to
the current user.


> IMHO all permission checking should be done at the
backend, and by alib.
> is GreenBox::CheckPerm() the alib call to check
permissions?
>
> also, elaborate permissions are not a priority for the
Freetown release..

Sebastian Goebel wrote:
> Sure, permissions are checked by backend too. But for
some actions, the gui
> should not show actions which are forbidden to perform
to the current user.

yes, but only the backend know what is forbidden and what is
not,
doesn't it?

> yes, but only the backend know what is forbidden and
what is not,
> doesn't it?

Sure, thatswhy I want to request the backend before I show
links to those
actions.