Chris-Linfoot.net

• http://domino.example.com/blogs/tom.nsf/
  
• http://domino.example.com/blogs/dick.nsf/
  
• http://domino.example.com/blogs/harry.nsf/
  
• and so on...

This does make for some very long URIs, though, which users would need to remember. Of course, you could mitigate this by offering an index page but why not go a stage further and give the blogs meaningful host names?

• http://tom.example.com/
  
• http://dick.example.com/
  
• http://harry.example.com/
  
• and so on...

Here's the problem. If you just use DNS to do this and point all of these names at the IP of domino.example.com, or via a CNAME to domino.example.com, then

1. It becomes possible to visit blog sites using URIs that you hadn't intended to work:
   
   

   http://tom.example.com/blogs/dick.nsf/

   
   
2. You still have long URIs to deal with, incorporating the full path to the .nsf container and possibly revealing a little more about your Domino data hierarchy than you might like.

Each of these virtual blog sites would need a Web Site Document in the Domino Directory:

By modifying this document slightly and adding two subsitution rules, you can effectively ring fence blogs hosted on the same physical server (http://tom.example.com/blogs/dick.nsf/ no longer works) and provide shorter URIs to readers.

First, modify the web site document

Check the Configuration tab. It probably looks something like this to begin with:

Second, add two subsitution rules to the Tom's blog web site

The first has the effect of making all URIs relative to the blog root appear to be relative to the web site root and the second undoes this in the event that some action like a form submission causes a redirect to the absolute URI of the blog container and not to the site root.

Thus http://tom.example.com/ and http://tom.example.com/blogs/tom.nsf/ both work, with the former being the usual behaviour, but http://tom.example.com/blogs/dick.nsf/ does not work and will return a 404 error.

In other words, virtual blog sites implemented this way are completely isolated from each other, as they should be.

Side effects

Setting up your sites this way also means that http requests for Domino system databases also fail with a 404, for example http://tom.example.com/names.nsf/

If you plan to use authentication on these sites, perhaps for administrative purposes, then you need either to use HTTP authentication or, if you require Domino session authentication, you may also require substitution rules to restore access to /names.nsf and /domcfg.nsf.

Watch it working

Check this story's permalink in your browser address bar. Note that it contains neither a path relating to the location of the .nsf container in the Domino server's file system nor any reference to the .nsf container itself.

As I said already, this site is a Blogsphere blog but this technique works on DominoBlog (Steve's Project DX template) too, and therefore almost certainly on the 7.0.2 blogging template derived from DominoBlog.

Visit Ben at jaffacake.net to see it in action there.

Category: SnTT
Technorati: Blogsphere Domino+7.0.2 SnTT Web+Site+Document

1. Pascal07/02/2007 14:08:33

This was precisely the piece of advice I was looking for. I can't "stand" the long URLs, and hence was trying to make them smaller.

I have a database called "test.nsf" at "www.domain.com/domain/test/test.nsf" and so I added the website (test.domain.com) and the two substitution rules you suggested above.

Yet, it doesn't work. I get a 404 error. - Am I rightly assuming that this means that the address does not resolve properly, and that it's nothing to do with the design of the database?

I previously simply created a substitution on the main (www.domain.com website) with the incoming URL "/test", which worked fine...

I realise this is not a support center, but I was hoping that you might have an additional hint based on your own experience!

Much appreciate any help! - Thank you.
Pascal

2. Chris Linfoot07/02/2007 15:19:25

404 means it hit the Domino web server and the web server couldn't find what it was asked for.

If you watch the Domino console while trying to load your new short URI, if you get a 404 at the browser, you should see:

07/02/2007 15:17:06 HTTP Web Server: Couldn't find design note - blah [/linfoot/blogsphe.nsf/blah]

The part in the square brackets tells you what the web server was trying to load relative to the Domino data directory. This should be the only clue you need.

One other thing. If you create a new site and substitution rules, you need to restart the http task before it will work anyway.

3. Pascal Koller11/02/2007 13:24:32

Strangely enough, I tried to see any activity in the server console, but there is no activity if I try to open the relevant database.

When I open CMD and try to ping the address test.domain.com, I get a different response (i.e. IP address) than if I ping www.domain.com. - Any clue how that can make sense?

Thanks
Pascal

4. Chris Linfoot12/02/2007 09:19:18

Well that would certainly appear to be at the root of your problem.

If DNS for your new site (test.domain.com?) is pointing to the wrong place, then the Domino server at www.domain.com will never be hit by the http request and you'll see no console activity there.

If a web server (whether Domino or not) is listening at test.domain.com, then a 404 response is pretty much inevitable.

This isn't a Domino config problem. You need to fix the underlying DNS issue.

5. Pascal20/02/2007 12:31:55

Thank you for your kind reply! - Your answer was (obviously) spot-on; I'll have my DNS entry amended accordingly. - I got the site to work, including the rules you had suggested in the original blog entry above. All great! - So, thanks again.

One thing still doesn't work. I have implemented the solution suggested above on two databases, one with no protection (i.e. Anonymous has Reader access) and one with access restriction (session authentication is enabled on this particular website document).

In both databases, I have defined a number of forms (e.g. "$$ViewTemplate for View1" etc.) as well as a form "$$ViewTemplate for NavigatorName" (and it is this Navigator, which is defined in the Launch properties of the database).

The "unrestricted" database works fine. I can jump directly to any document I want (e.g. www.domain.com/links/PermaLink) or simply to the database's main entry page (www.domain.com).

As for the "restricted" database, the behaviour isn't quite so straightforward: once I am logged in, I can access the database by typing "www.domain.com" (or any document), but if I try this without being logged in, I get an error saying "A view of that name cannot be found" or (if I go for a document) "the entry cannot be found in the index".

This seems to be due to the user not yet having logged in to the database yet and therefore the view (or entry) defined in the Form "$$ViewTemplate for NavigatorName" cannot be found.

However, shouldn't the database just jump to the login page and then - once authenticated - redirect the user to the relevant navigator page?

If not, what Launch properties should I set the database to? Or what form do I need? - How do I get the database to login the user and then go the right way?

I appreciate that this does not strictly relate to the original blog entry, and I hope you'll forgive me for posting here anyway. I am lost...

Thank you.
Pascal

6. Chris Linfoot20/02/2007 17:41:51

Session authentication requires access to names.nsf and the database containing the login form. If they are both in the Domino root data directory then you will also need a substitution rule to restore access to them. Otherwise the system will be looking for www.example.com/path/database.nsf/names.nsf instead of www.example.com/names.nsf.

7. Pascal21/02/2007 08:11:41

Thank you, I have included that - following the advice of your initial blog entry.

The strange thing (at least in my mind) is that when I call a specific view, e.g. www.domain.com/viewname?openview, I get straight to the login and then to the relevant database.

If I enter, however, www.domain.com, I get the error, as it doesn't seem to go for the "default" view.

Thanks.
Pascal

8. Mark Schultz06/03/2007 06:49:12

Thank you, Master Linfoot (being a yank, that's "Master" as in "Mastery"). I have now plundered my evening and come away with some pleasant results. I have two issues, tho -- hopefully they don't require too much rearchitecture to resolve.

Root substitution loses HTML (sub)directory?
To keep certain FCKEditor tweaks and favicon separate from my primary domain, I created a subdirectory in my HTML path, and have been using that for my blog: domino\html\myblogdomain. Prior to hacking around learning about the consequences to malformed substitutions, everyhing pulled up fine, and http://myblogdomain.org/blogs/blogdb.nsf found the favicon.ico in that subdirectory.

Post-substitution, I open http://blogprefix.mydomain.org/favicon.ico, and I now reach the primary HTML directory, up one level. I am assuming that the root redirect is mashing something, and Domino is defaulting to the server standard?

Authentication across subdomains
So now I've done it: original community portal is at http://mydomain.org/portal.nsf. Shining new clean URL blog has now been shoved by subs rules to http://blogprefix.mydomain.org. I figured, ignorant as I am, that authenticating to the former might just possibly carry over to the second, even though they are listed now as distinct web sites. No go, though both sites are Session Authentication (single server).

I hope I don't have to screw around with SSO and multi-server configs?? That would be unfortunate, this is a single box and simple architecture, I wouldn't want to muddy this all for URL niceties (maybe for URL securities, but this is a small non-profit... stakes are as small as the lack of equity).

Thanks for any ideas you might drift my way.

Mark

9. Chris Linfoot09/03/2007 10:04:21

1. You either need to add further substitution rules for certain types of content to restore access to the HTML directory, or you need to add those elements to the .nsf container which contains the blog. The latter isn't difficult. To create for example favicon.ico, you'd just create an image resource and name it favicon.ico.

2. You do need SSO, I'm afraid.

10. Dmitriy31/07/2007 17:33:15

When created substitution rules

/* -> /dir/site.nsf/*
/dir/site.nsf/*-> /dir/site.nsf/*

dont work defaul maping for icons

domino generete url request for icons in view
icons/abook.gif [/dir/site.nsf/icons/abook.gif]

How to solve

11. Chris Linfoot31/07/2007 20:46:16

Easy. Add another substitution rule:

/icons/* -> /icons/*

Unable to post a comment? Please read this for a possible explanation...