Hi Shai-<br>
<br>
That sounds really cool. Just a few thoughts:<br><ul><li>
I'd be concerned about allowing people to post any kind of content, in
particular javascript or php. So the first thing on my list to check
would be the input filters that people are allowed to use.</li><li>
Besides that, maybe it would be helpful if you could list what
permissions and admin functionality you are planning on enabling, so
people could think about security with these features in mind.</li><li>
Lastly, since you explicitly asked, I can't personally recommend that you do this on a production
server, but if you want to go down this route, I'd 1) try to setup some
kind of apache jail for the d7 sandbox (this would separate the d7
system from the rest of your stuff) and 2) make sure that I had
frequent off-site code and database backups for all of my client sites.</li></ul>
Again, cool idea.<br>Best,<br>tim<br><br><div class="gmail_quote">On Tue, Nov 3, 2009 at 9:46 AM, Daniel F. Kudwien <span dir="ltr"><<a href="mailto:news@unleashedmind.com">news@unleashedmind.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">> I had planned to give people a LOT more access than that. I<br>
> certainly was *not *going to give folks FTP or administer<br>
> users permissions, but otherwise I was thinking of giving<br>
> authenticated users a lot of permissions. I'm planning on<br>
> having the Demonstration Site module<br>
> <<a href="http://drupal.org/project/demo" target="_blank">http://drupal.org/project/demo</a>>running to take snapshots on<br>
> cron (and I wouldn't give people admin privileges on that,<br>
> obviously). So I could set the site back if someone comes<br>
> along and messes things up.<br>
<br>
</div>Handing out administrative permissions needs careful thoughts. In<br>
<br>
Add Demo Secure module<br>
<a href="http://drupal.org/node/375411" target="_blank">http://drupal.org/node/375411</a><br>
<br>
I outlined the critical steps to hand out _all_ administrative permissions<br>
for the sake of my Total Admin IA Revamp proposal earlier this year, which<br>
allowed to access and alter everything in Drupal.<br>
<br>
That, of course, required additional steps. However, if you skip the<br>
following, then you should be fine:<br>
<br>
:: WARNING: THIS LIST MAY NOT BE COMPLETE ::<br>
<br>
- administer permissions: Prevents granting access to PHP permissions,<br>
filter configuration.<br>
<br>
- administer filters: Prevents access to filter configuration.<br>
<br>
- administer languages: Prevents access to translation import functionality.<br>
<br>
- administer demo site: Prevents access to Demo site administration.<br>
(Attention: the "Reset" block can still be used, and can be enabled by<br>
anyone who has "administer blocks" access.)<br>
<br>
<br>
Additionally, I recommend to install a CAPTCHA or spam protection module.<br>
If you want to grant access to "administer site configuration" (which<br>
currently is the global access trigger for everything below admin/config),<br>
then people will be able to enable/disable modules. To prevent certain<br>
modules from being disabled, you should put the following in their .info<br>
files:<br>
<br>
hidden = TRUE<br>
required = TRUE<br>
<br>
<br>
Please note that it's perfectly possible that some new functionality<br>
(authorize?) could make all of this a bit harder.<br>
<br>
sun<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Tim Loudon<br><br>