Jesse Guardiani wrote:
On Sunday 23 February 2003 23:21, Jesse Cablek wrote:

Kurt Bigler said:

on 2/22/03 8:37 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:

----- Original Message -----
From: "Kurt Bigler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 22, 2003 10:53 PM
Subject: Re: [sqwebmail] NEW: domainmap Patch


<snip>

Pardon my ignorance, but doesn't this patch make logindomainlist
un-needed? Since you want to make this seamless, then why would you still
want the domain list in the dropdown?


Well, I'm sure someone could think of a reason why they like the drop-down,
otherwise it would never have been created.


Oh I understand it's use on a fully virtual hosted server, and even on a mixed one (as you can always select a blank entry for system accounts). I just meant with the patch is it needed at the same time - but I see now that it can still be used well with it.


Besides, my patch doesn't obsolete the 'logindomainlist' file, it complements
it. If you specify a 'domainmap' file with the following entry:

[...]

Then the 'logindomainlist' dropdown will still exist, but the 'mydomain.com' option will be the default! This makes the 'logindomainlist' file even more user friendly, I think.


Alright, understandable.
Though you can use this patch without the logindomainlist and it will still work as intended using a hidden form field, correct?




I personally would prefer to keep this separate. Then hosted users
wouldn't see a dropdown list for my personal domains, and vice versa. As
Jesse G said earlier, these 2 lists provide completely different
functionality.

logindomainlist - gives users a dropdown choice of what domain to use
domainmap - dynamically assigns the domain so the user doesn't need a
choice

Please correct me if I'm wrong on these points?


Not wrong, but missing some information. See above.


Thanks for the correction - at least this gives alternate uses that can be used for the documentation ;)



Additionally, this patch wouldn't work in my current setup as I
authenticate against vchkpw AND shadow - hence some requiring the domain,
some not. So in the documentation be sure to mention where this patch
wouldn't specifically be used.


Hmmm... hadn't thought of that. Can you access your system accounts with

[EMAIL PROTECTED] in the userid field?


Nope.


I'd like this patch to be as flexible as possible, so if there is a way
to accomodate mixed system and virtual accounts, I'll implement it.


Possibly have it only select a default domain and/or put in a hidden form field with the domain IF it shows up in logindomainlist OR domainmap.


With logindomainlist you can still leave it as a blank option - and it should work fine with system accounts. SO if the domain you're accessing it from doesn't show up in either, then leave it as normal and allow full choice up to the user.

Thanks for the comments!


No problem.


Personally, I don't think I'll use this patch - I see it's functionality and I probably would have previously, but since I've learned a lot more, specifically about SSL in httpd then I use https with SqWebMail. httpd doesn't allow named virtual hosts for https so this functionality wouldn't much help me.

Well I technically 'could' set it up but I'd be getting all sorts of certificate errors, so I'm probably not going to. Keep up the work though, I'd like to see it implemented for a time that SSL "may" be able to support virtual hosts on 1 IP :)

That's nothing this patch can fix!

/jesse




Reply via email to