Item1970: Cannot create new web in 1.0.6

Unable to create a web in 1.0.6

Have the same issue in 1.0.6 with both Template and ApacheLogin as well as regular TopicUserMapping and a custom mapping. In other words: yes my wacky custom setup is where I noticed this bug but it's also there with the defaults.

Steps to reproduce behavior:

1. Go to WebCreateNewWeb or ManagingWebs
2. Fill out form and click 'Create new web' button
3. Get directed to validation screen (suspicious request)
4. Click 'ok'
5. Get error from manage script "doesn't understand the 'validate' action"

Things I've tried to triage:

• Switch to default auth/user mapping
• turned off validation but it still tries to validate i.e. takes me to the validation screen.
• sudo to AdminUser

None of the above changes had any effect.

Just confirmed same issue with rename. No other cgi-scripts seem to generate this activity.

---

Switching off validation does not work on the current "stable" release. This and the newer wysiwyg on foswiki.org are enuf for a next minor release, alas the main actors have other things to do right now.

WebCreateNewWeb is a NatSkin-only feature (feature request for standard foswiki was not accepted / blocked by Kenneth). It should be fine in the latest NatSkin. Please tell me if it is still broken.

-- MichaelDaum - 25 Aug 2009

---

Already backed down to 1.0.5. Also I don't think it really had anything to do with Nat and WebCreateNewWeb because the ManagingWebs version exhibited the same behavior.

-- DrewStevenson - 25 Aug 2009

odd. I've created new webs (using ManagingWebs) with 1.0.6 on quite a number of systems, with no troubles.

very odd :/

-- SvenDowideit - 27 Aug 2009

From our conversation on IRC I think Drew has other problems than authentication.

-- ArthurClemens - 27 Aug 2009

Based on dld's comments further down our conversation on IRC I'm inclined to think we're running into the same issues with apache auth. What I find most frustrating is that our apache conf file was generated using the tool on foswiki.org and then we added in our auth piece. Even switching to Template Login instead of Apache had no effect on the validation script popping up to taunt us.

All of this wouldn't be an issue--or at least not a deal breaker--if the login script properly handed off to the manage script. Right now the manage script gets an action of "validate" instead of "createweb".

-- DrewStevenson - 27 Aug 2009

It's possible, but unlikely, that it's apache auth. Unlikely because once you are validated in the browser, and the core recognises you, it follows exactly the same path through validation as Template login. The behaviour above suggests that the validation key is being invalidated as soon as the request is posted, or "Create new web" is somehow failing to send back the key.

Possibilities that need to be eliminated are: you are using shorter urls, you have disabled cookies, you are missing write permission somewhere, you have javascript disabled.

-- CrawfordCurrie - 03 Sep 2009

• Wasn't using shorter urls initially (mid-way through redid our apache conf and starting using them to close a longtime request). In other words: happens with and without shorter urls
• cookies enabled (our apache auth doesn't work without them)
• write permission where? on the server? in foswiki?
• JS enabled

-- DrewStevenson - 03 Sep 2009

I don't know what to suggest. Can you reproduce this on an out-of-the-box install? If so, can you copy me with the LocalSite.cfg?

-- CrawfordCurrie - 10 Sep 2009

Unable to reproduce on 1.0.6 with our "live" site or with my test installation (both of which have NatSkin and friends).

I did however get the same behaviour on trunk with WebCreateNewWeb only. Created Item2055 for that. Perhaps it's a NatSkin problem.

DrewStevenson: I've on two occasions now had weird validation problems until I cleared my browser's cookies... would it be rude to ask if you'd tried clearing cookies?

-- PaulHarvey - 13 Sep 2009

Always worth asking about cookies. Pretty sure I did that for Safari, may not have in Firefox. I had to bring our test site down to 1.0.5 to keep working on making sure things we used on T* work under Foswiki (lot of customizations). It takes a while sometimes to get a new site setup but I'll try to get a couple new test sites this week for testing trunk and 106.

The thing that makes the most sense to me for a fix is to make sure you can pass the original "action" parameter to the manage script somehow. Right now the validation form sends back an action=validation param which confuses the manage script.

Meanwhile if this is blocking 107 and there are other key fixes you may as well release it. We've slipped our production schedule so this can wait at least a few more weeks if not until the 1.1 timeframe to get ironed out.

-- DrewStevenson - 13 Sep 2009

Thanks Drew. As I can't reproduce this, I'm dependent on you recreating the original conditions - or finding that you can't - so setting back to feedback from you.

-- CrawfordCurrie - 14 Sep 2009

I installed a clean full 1.0.6 install with a copy of our apache.conf and web creation works. I hooked into our Central Auth Hub and it still worked. Must be something in our old data or some custom bin script that came forward and hosed things up. I'll keep working in other changes and enhancements. I suppose it could've been an issue with the 1.0.6 upgrade package we originally used. Meanwhile unless I find something different it seems like this was a conf/upgrade issue not a release-blocking flaw.

-- DrewStevenson - 17 Sep 2009