The RegistrationApprovals are stored in
.../data/RegistrationApprovals
. The code in
TWiki::Store::RcsFile.pm
returns
it as a public web when calling for a list of known webs. That's why it shows up in the sidebar navigation as a web...which we don't want.
This can be resolved in either of the following ways:
- filter out
RegistrationApprovals
in the store impl
- rename
RegistrationApprovals
to _RegistrationApprovals
- move the
RegistrationApprovals
out of the data directory
--
TWiki:Main/MichaelDaum - 15 Jun 2007
Most logical place is
pub/_work_areas/_RegistrationApprovals
--
TWiki:Main.PeterThoeny - 15 Jun 2007
... or
pub/_work_areas/RegistrationApprovals
--
TWiki:Main.MichaelDaum - 15 Jun 2007
This one has been bugging me for a long time. Glad you decided to fix it!
You can put it in _work_areas; just use
$session->{store}->getWorkArea('RegistrationApprovals')
. That's where it would be if registration was a Contrib - which it ought to be, really.
--
TWiki:Main.CrawfordCurrie - 16 Jun 2007
Right now, the directory is configured in
$TWiki::cfg{RegistrationApprovals}
and defaults to
$TWiki::cfg{DataDir}/RegistrationApprovals
. I'd opt to remove it from
configure
as I can't imagine a case where one would know better where to put it than the store impl.
--
TWiki:Main.MichaelDaum - 19 Jun 2007
I have just had someone else suffering as a result of the use of /tmp for temporary files. We need a safe, unbrowseable directory where we can store session files, that doesn't get eaten whenever the server is rebooted.
In fact there are several places we need:
- An unbrowseable work_areas dir
- The current _work_areas is held under pub, which is bad because by default it's browseable, and therefore contrary to the documentation.
- Must either move it, or make it unbrowseable by default
- A browseable place for plugins to put "stuff"
- We have that; a plugin can attach files to any topic. I checked though all the checked in plugins, and with the single exception of HeadlinesPlugin that's how it is used.
- A secure place to store sessions and passthroughs
- We currently use
/tmp
by default, which is bad - it is insecure and gets wiped without warning by admins
- A secure place to store regsitration approvals
- Currently in data/RegistrationApprovals, which is absolutely the wrong place
- This has to be more persistent than sessions
So here's what I'm proposing to do:
- add a dir in the root, called
working
. Add .htaccess to make it unbrowseable.
- move pub/_work_areas to the root, to
working/work_areas
.
- add working/tmp for sessions and passthroughs
- add working/registration_approvals for registration approvals
- remove the {RegistrationApprovals} option from
configure
and standardise on {WorkingDir}/registration_approvals instead.
If you can see any problem with this
shout now.
--
TWiki:Main.CrawfordCurrie - 19 Jun 2007
Not sure I understand, nobody is going to shout and flame.
The current
pub/_work_areas
dir is unbrowseable by default, it has a .htaccess file that denies access.
Having said that, I think it is a sensible thing to add a
working
directory for
tmp
and
registration_approvals
. For compatibility I suggest to leave the
_work_areas
where it is for now, and to announce that it will be moved to below
working
in the release after 4.2.
--
TWiki:Main.PeterThoeny - 20 Jun 2007
Why is it incompatible to move the
_work_areas
out of
pub
? Which code does not use
TWiki::Func::getWorkArea()
?
--
TWiki:Main.MichaelDaum - 20 Jun 2007
It isn't, AFAIK. I made the changes as described above. Not sure exactly what we should ship in the way of .htaccess files; I have created one at the root of
WorkingDir
. Note that the upgrade for working files should be seamless (all handled in
configure
)
--
CC
Compatibility:
- On upgrade, admins need to move work area data to the new location, or extensions will not be able to find it. A similar scenario happended with TagMePlugin where the tagging data was moved from
pub/TWiki/TagMePlugin
to pub/_work_area/TagMePlugin
(some support questions have been raised on this)
- the change is handled automatically by
configure
. How effective this is depends on the amount of testing/feedback between now and the release, I guess.
- Extensions that use the work area to store browser accessible content will break (we do not know what users do in unpublished extensions.)
- that's true; but the doc is quite clear that the area is "not browser accessible", and AFAICT all public plugins have respected that (with the possible exception of HeadlinesPlugin)
That is the reason why I suggest to leave the _work_areas where it is for now, and to announce that it will be moved to below
working
in the release that follows 4.2.
Let's take this to the next release meeting so that customer advocates have a voice.
--
TWiki:Main.PeterThoeny - 21 Jun 2007
The current implementation moves the _work_area when you run configure. That is a beautiful way for the upgrader to easily get going.
What we need to do is
- Review all public plugins that they use the proper API and no hardcoded directories.
- Evaluate is violating plugins need to be fixed.
Non-public plugins which uses non-public API will be broken anyway with all the code refactorings done from 4.1 to 4.2.
Please note that a.htaccess file in a directory often has no function at all. They only come to effect if enabled in httpd.conf. You cannot count on a .htaccess file to be effective. So the new working directory needs to be added to
ApacheConfigGenerator and to the default twiki_httpd_conf.
I think moving things into working in small steps will be more painful than doing it all at once. And with the nice upgrade method in configure I do not see this as an issue. I wish other upgrade pain had been resolved as elegantly as this one. It sort of sets the standard from now on
--
TWiki:Main.KennethLavrsen - 21 Jun 2007
A
couple of carifications above. I know a
.htaccess
may not be used, but I think it's better to provide one than not.
IMHO
ApacheConfigGenerator doesn't get enough press. Is it linked from the installation instructions yet?
--
CrawfordCurrie - 21 Jun 2007
OK, convincing arguments to move _work_area as well.
I run configure, but it did not move the
pub/_work_area/TagMePlugin
directory to
working/working_area
. However, the tagging data was still accesible in the old location. Also when manually moved to new location.
--
TWiki:Main.PeterThoeny - 21 Jun 2007
I should have been clearer; it
copies the old data to the new location, and warns you (in configure) to remove the old. Not sure what "also when manually moved to new location" is meant to mean.
--
TWiki:Main.CrawfordCurrie - 22 Jun 2007
After running configure, the
pub/_work_area/TagMePlugin
was still there, and there was no new
working/work_area/TagMePlugin
. TagMePlugin still worked. I then moved
pub/_work_area/TagMePlugin
to below
working/work_area/
and TagMePlugin still worked.
--
TWiki:Main.PeterThoeny - 22 Jun 2007