A little matter of www.

[Charles Capps]

Ok, here's the problem.

I always refer to my site without the www. prefix. Every link everywhere (that I know of) refers to it without the www. prefix. My UBB is configured not to use the www. prefix.

Note a trend? http://www.aota.net/ubb/smile.gif

My problem is that my users are ALWAYS tacking on the stupid www. prefix when they _TYPE_ in my URL. So, when they visit my UBB, their cookies get broken, as all the forums and threads off the main page are without the www. prefix. It's more than annoying: they then mail me asking what's wrong, what I've done to the code, etc. I finally tracked down what was causing this last night (a lot of good beta testing did!).

So, how do I fix this? Is there anything like an SSI script I can call from my pages that will ensure that the user's not accessing using www.? Could something be configured server side to automatically forward any user that accesses anything using the www. prefix to the appropriate document without the www.?

Is there another solution I've overlooked?

Thanks!

------------------
"Okay, so I'm not "SANE" so to speak, but uh... I'm the lovable kind of psycho"
http://solareclipse.net/

[Deb]

There really isn't much you can do about that outside of what you are already doing. We could, as your host, take the 'www' out of our DNS entry but that would make it so anyone using the www would get an error in the browser saying something like "no dns found" I would assume finding your site 'incorrectly' is better then not finding your site.

It's common to access via www like it or not.... you may (as I duck and hide) want to consider recoding your site to include it and of course the option to not use it is always there....

Deb

[jenili]

Charles,
Forget reraining your users or trashing your preferred URLs. Why not hack the UBB code and add a second cookie header? All you need to do is repeat the Set-cookie header with a dot in front of your host name. The cookie header with the dot will work for X.solareclipse.net, where X is anything, but won't work for solareclipse.net. The cookie header without the dot will work for solareclipse.net, but won't work for X.solareclipse.net. The nice thing is, the headers that don't work fail gracefully; that is, silently. Then you'll end up with the same cookie for both host names.

This is a two-minute change, despite UBB's butt-ugly code. grep everything for "ookie:" to find it and the change will probably be pretty clear. If you're not handy with perl, let me see the scripts (I only have freeware version, with home-grown mods to add the functionality I care about) and I'll put the change in for you.


------------------

jeni

[Charles Capps]

Deb: Thought so - I don't want /that/ done, as my users will freak out. And I happen to like my domain wwwless. http://www.aota.net/ubb/smile.gif

Jenili: I'm quite handy at UBB hacking, I customized my copy myself, and have released many of the hacks (auto-sig post, delete-message-from-thread) to the public at the UBB's UBB in the Code Hacking Forum.
However, I honestly don't want to touch the cookies! The last time I did that was during the Y2K-1 fiasco, and the board was down for a month and a half while I figured out what I did wrong! *LOL* If you could point out a subroutine or two where the exact code could be found and changed, I'd feel much better about it (and test it elsewhere...). http://www.aota.net/ubb/smile.gif

Thanks!

------------------
"Okay, so I'm not "SANE" so to speak, but uh... I'm the lovable kind of psycho"
http://solareclipse.net/

[jenili]

Hmm. OK. I've located a copy of the commercial UBB and am looking at it now. They use a standard-looking cookie-lib.pl to get cookies, but they do all their cookie setting using JavaScript. I don't do much JavaScript, so will have to hit some dox somewhere to verify that you can set cookies by domain using JavaScript. Will look around tonight and let you know. The bad news is, since they've done it this way, you'll be editing a lot of code. http://www.aota.net/ubb/frown.gif Essentially, for every line that says
document.cookie=X
you'd need to add another line that says
document.cookie=X; domain=.domain

That's in Ultimate.cgi, ubbmisc.cgi, postings.cgi, forumdisplay.cgi, edit.cgi, announce.cgi, all 3 cpanelX.cgi's, and ubb_library.pl. In short, pretty much everything. Yuk.

If you want to try it, you might mess with the cpanelX.cgi's first. Search for
document.cookie =
to find what to duplicate; don't replace that line, but copy it to a second line and replace the final ";" with
";domain=.solareclipse.net;"

Then you can test it with your control panels before you try to go systemwide with it.


------------------

jeni

[hearts]

i got a question if ya don't mind? I have seen the term "vanity site" mentioned alot. If I remember correctly, isn't this where your domain without the www and with the www could be totally two different things?

If this is true, couldn't you have a redirect page on the www sending them to the UBB without the www url?

I wonder though, why you opted to set your links/UBB the way ya did. Any real reason? It seems it would just be easier to have everything done with the www. Less confusion and omits frustration. ( i read, you like it www less. giggle)

[This message has been edited by hearts (edited 03-13-99).]

[jenili]

Dunno about the rest of the world, but in my environment a "vanity site" is an individual's Web presence -- a site that may not have any earth-shattering content or subject matter, but is just someone's footprint on the Web. And a "vanity URL" is when people on the Web servers we maintain ask for a short (or specific) URL -- done as a directory alias or URL forward -- like www.asu.edu/computeraccounts instead of www.asu.edu/it/fyi/start/accounts.html. They want their subsite to be more attractive to search engines and easier to type/remember, or just to look more important.

But you've got a good point, hearts. Charles could add some code into each one of those scripts (or, better yet, into UltBB.setup, since everything calls it first) that looked sorta like this:
if (($ENV{'HTTP_HOST'} =~ /www/) && ($ENV{'REQUEST_METHOD'} eq "GET")) {
print "location:$CGIURL/$ENV{'SCRIPT_NAME'}\?$ENV{'QUERY_STRING'}\n\n";
}
or something similar to that (I'm not sure of my "and" syntax). It wouldn't affect the POST transactions (you can't pass the STDIN around as well as the query string, alas). But the main problem is probably with that initial entry point anyway; once they get bounced to a non-www. URL, everything is relative and they oughta be fine.

Not all browsers support the Host header, but probably the ones that don't are in a severe minority and won't be hitting a UBB anyway. The 4.x browsers do, and it's been around long enough that I'm confident the 3.x browsers do too. This could be a reasonably elegant solution for you, Charles, more in line with your original idea. Whaddya think?


------------------

jeni


[This message has been edited by jenili (edited 03-13-99).]

[Charles Capps]

Well, 95% of my audience uses a 4.x browser, so that last hack should work... *puts it on the To Do list* Ugh, so much stuff, so little time.

------------------
"Okay, so I'm not "SANE" so to speak, but uh... I'm the lovable kind of psycho"
http://solareclipse.net/