| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | other |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | needs backport to D7 |
Issue Summary
IIS 7 works without much hassle with PHP applications and supports URL rewriting since about a year. There's now a real push by Microsoft to spread IIS 7 + fastcgi + PHP + urlrewrite with their new Webplatform installer.
IIS 7 is likely the most prevalent webserver on "wannabe" developer desktops (XP Pro, Vista Ultimate, Windows 7 XYZ) and, in my experience, much easier to configure (for newbies) than Apache.
We've been shipping Drupal with an Apache configuration file for a long time. Why not ship Drupal with a default web.config for IIS 7 to make Drupal even more accessible for new developers?
A side benefit would be to allow established .NET shops an easy entry point to use Drupal on their existing infrastructure.
A good web.config would
- make clean URLs work (big deal)
- make file protection work (big deal)
- make caching settings work
- make index.php the default document
- make index.php the 404 error handler
Preemptive:
But should we also ship with lighttpd configuration files? nginx? [favorite du jour]?
Maybe, but I do not think supporting IIS 7 means we need to cater to marginal servers as well.
Comments
#1
Microsoft pushing for something should be enough reason to won't fix this.
#2
+1, for several reasons, as it makes drupal more widdespread, and opens up a whole new slew of drupal sites, which are currenly having a vendor lock-in, and makes moving hosts a lot easier when they go over to a LAMP host finally, as we can offer them a robust upgrade path.
about your Preemptive: we should, if they manage to obtain a marketshare of 10% (when will drupal be running on google servers?)
- http://en.wikipedia.org/wiki/Web_server
- http://survey.netcraft.com/Reports/200901/
#3
I would be in favor of this. This gives a better out of the box Drupal experience on more web servers then just Apache.
#4
After the massive amount of issues around clean URL's and the private file system, I have to agree, there seems to be no clear cut, simple way to make these things work on an IIS shared hosting platform, it would be great to have an easy way to do all of this, and for Drupal to just work with IIS7.
#5
Windows is running 30% of all websites? ... I'm depressed now. I'm very, very depressed.
#6
I think this is a good idea. Granted IIS is not open source, but we are trying to make Drupal more accessible not take a radical hard line FOSS stance.
Sure I would love to see MS have less market share in serving web pages (and IE take a nosedive) but we should remain focused on spreading Drupal and making it the CMS of choice. Let's not cut off our nose to spite our face.
#7
+1
#8
I recently tried the Web platform installer (aka WebPI), and it's one of the easiest ways to get Drupal running on Vista / Seven for a Windows development machine. (ANd yes, WebPI also works on Home Premium editions).
Here's a simple web.config, adapted from Acquia Drupal.
#9
Another reasoning is that IIS, being very easy to install, will be installed a lot by people who are less informed when it comes to security. In other words: someone who manages to get a custom lighty running, has a bigger chance of being security aware, then a user clicking on three [next »] buttons.
We -as Drupal- should avoid opening vulnarabilities on those people's machines. It will backfire: if word gets out that 'installing Drupal on IIS opens security holes', even if it technically is the users fault, we get the blame.
If avoiding that, is as simple as adding a simple file, I see only reasons to include that file.
Downside is that is will need to be maintained, to avoid giving people a false sense of security.
#10
I don't agree with that at all. On Ubuntu just type sudo tasksel install lamp-server and you're done. And IIS 7 is pretty rock solid secure from the beginning.
Obscurity doesn't mean security, and ease of use doesn't mean insecure.
#11
Seems like an obvious win. Just needs a reviewer to move it to rtbc.
#12
I think I'd be fine with this, too. The only real reason not to do it is the "slippery slope" argument, but when we're talking about this type of critical security (not to mention usability) enhancement, I'm not sure that holds much weight.
#13
IIS 7 out of the box is pretty darn secure. I have successfully unsecured Apache based setups faster then IIS based setups because of familiarity based causes.
#14
I'm running with that for a few weeks now. Works flawlessly out of the box.
#15
Ok, let's do this then.
Committed to HEAD.
#16
Same works for Drupal 6 (given this was adapted from Acquia Drupal)?
#17
--- /dev/null+++ web.config
Shouldn't we hide this file from prying eyes?
Powered by Dreditor.
#18
@sun: there is no real need to. We don't hide CHANGELOG.txt, I don't see why we should hide web.config. On Windows systems, this file is automatically hidden by IIS.
#19
We need automated tests for this: #771430: Add test bot running IIS + Windows
#20
The “Protect files and directories from prying eyes” rule differs from that in .htaccess. It omits .make files and adds .svn-base files. I assume this wasn't intentional?
Also, the file does not implement the protection added in #581706: Protect .git, .hg and .bzr directories in .htaccess. Is that possible simple by extending the pattern in the <match url=""> rule?
This patch has not been tested.
#21
+++ web.config 15 Apr 2010 20:50:29 -0000@@ -1,43 +1,43 @@
- <match url="\.(engine|inc|info|install|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svn-base)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$" />
+ <match url="\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$" />
Am I blind or is .config not added here?
Also, what about .config in .htaccess?
Powered by Dreditor.
#22
This .config is irrelevant except on IIS, and on IIS it is unbrowseable unless the IIS administrator changed that parameter. That would be a really weird change.
#23
Let IIS users test? I can't see what could break with this patch.
#24
Committed to CVS HEAD.
#25
Automatically closed -- issue fixed for 2 weeks with no activity.
#26
Same works for Drupal 6 (given this was adapted from Acquia Drupal)?
#27
This works; I'm running with such a web.config on my dev server for several months.
I've specifically tested again:
block sql / module / inc
block favicon.ico with a cheap IIS 404 but not misc/favicon.ico
Here's a reroll of the latest Drupal 7 web.config that should still work on D6 (so, _with_ a query string).
#28
Here's the latest web.config by Mark Brown and the MS webteam converted to a patch. There are some questions open regarding the post-install files (required for WebPI?) and the allowed files list.
#29
Do we need to bump that to D7 again?
#30
Yes, looks like.
#31
Here's a patch for D7. Only change compared to the D6 one is to deal with drupal_environment_initialize.
#32
Ruslan got back to me and no, postinst serves no purpose. Has been removed in attached patch. Also wrapped a few non-config comments at 80 chars.
#33
CVS version patched and installed with minimal version on Windows2008 without any problems
#34
The rewrite section needs comments to help with installs like those in #980128: web.config error when upgrading from D6 to D7 on IIS missing urlrewrite and/or needs requirements docs & faqs.
#35
#36
I'm not a IIS user but this looks reasonable for inclusion in 8.x. Committed. Requires more review before this can be committed to 7.x.
#37
Tagging, so I don't lose track of this.
#38
i used 2 last patches on drupal 7 web.config
i have not clean url if patch this section
- <action type="Rewrite" url="index.php?q={R:1}" appendQueryString="true" />+ <!-- Pass all requests not referring directly to files in the filesystem to
+ index.php. Clean URLs are handled in drupal_environment_initialize(). -->
+ <action type="Rewrite" url="index.php" />
Windows web server 2008 R2 iis