• WCWEB and Host Headers

    From CHRIS CRANFORD@1:124/5013 to All on Thu Jan 31 19:10:38 2019
    Date: Mon, 12 Apr 2004 23:14:49 -0400
    From: CHRIS CRANFORD
    To: HECTOR SANTOS
    Subject: WCWEB and Host Headers
    Newsgroups: win.server.wish.list
    Message-ID: <1081826089.33.0@winserver.com>
    X-WcMsg-Attr: Rcvd
    X-Mailer: Wildcat! Interactive Net Server v7.0.454.5
    Lines: 92

    Hector -

    I wanted to bring this up before I forget what I was thinking earlier
    today about this... and get your opinion and others as well because I
    am not sure what the goal is in order to offer this.

    But with that in mind, lets assume for the moment we take a multiple
    phased approach. I'm coming from the mind-set that the demand is to
    be able to have multiple WCWEB domains point to different WWWROOT
    directories.

    So, lets assume the following setup similar to things here:

    Security Profile #1 - SP1
    Domain: tkdsoftware.com

    Security Profile #2 - SP2
    Domain: petsutopia.com

    Security Profile #3 - SP3
    Domain: [nothing]

    Now, as the web server stands today, we have:

    wc:\http\public
    wc:\http
    wc:\http\template

    These are the major player directories.

    Now, could WCWEB be capable of reading the HTTP 'Host' header if it is
    passed and do a lookup against the domains defined in all the security profiles?

    If so, then could the following logic be implemented:

    Request: http://www.petsutopia.com (not authenticated)

    1. WCWEB sees that the session isn't authenticated and the URI is not
    referring to a protected document, so the request gets sent to
    http://www.petsutopia.com/public/

    2. WCWEB sees the wc:\http\public\default.htm request come in and it
    checks the web root folders in the following order:

    Check Host Header wwwroot directory if exists
    wc:\http(petsutopia.com)\public -->
    wc5\wwwroot\petsutopia.com\public

    Check Computer Config wwwroot directory if exists
    wc:\http(tkdsoftware.com)\public -->
    wc5\wwwroot\tkdsoftware.com\public

    Fall back to original logic
    wc:\http\public -> wc5\http\public

    3. When user logs into the web server, requests for protected
    documents would follow a simliar pattern:

    wc:\http(petsutopia.com)\default.htm ->
    wc5\wwwroot\petsutopia.com\default.htm
    wc:\http(tkdsoftware.com)\default.htm ->
    wc5\wwwroot\tkdsoftware.com\default.htm
    wc:\http\default.htm -> wc5\http\default.htm

    4. When templates are requested, simliarly:

    wc:\http(petsutopia.com)\template\XXX.htm ->
    wc5\wwwroot\petsutopia.com\template\XXX.htm
    ...
    wc:\http\template\XXX.htm -> wc5\http\template\XXX.htm

    I know that when (or if we) get to this point to do this, it is going to
    be a BIG change and require loads of testing ... Not sure when you have
    this slated on the project timeline, but since this idea came to my
    head, I certainly wanted to pass it along to you.

    Just to recap, for non-authenticated sessions, the host header would be
    used to initially determine the wwwroot directory path. If that path
    does not exist, try the domain for the computer running wconline. If
    that path does not exist, default to the current directory logic.

    For authenticated sessions, we could just use the security profile
    domain to determine the web root directory path instead of then relying
    on the host headers (unless you want to always carry this thru
    regardless).

    Anyways, gonna grab some TV.. Chat soon.

    Thanks,
    Chris
    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
  • From LUCAS HEUMAN@1:124/5013 to All on Thu Jan 31 19:10:38 2019
    Date: Wed, 29 Dec 2004 19:32:19 -0400
    From: LUCAS HEUMAN
    To: CHRIS CRANFORD
    Subject: RE: WCWEB and Host Headers
    Newsgroups: win.server.wish.list
    Message-ID: <1104366739.33.1081826089@winserver.com>
    References: <1081826089.33.0@winserver.com>
    X-WcMsg-Attr: Rcvd
    X-Mailer: Wildcat! Interactive Net Server v7.0.454.5
    Lines: 156

    I know it has been a long time since this was posted. But I been thinking about how I would like to handle this same situation also.. but was thinking more of a Conference path configuration... Example being that each domain would have a different Email Conference area associated with it or ..

    Your example modified..

    Security Profile #1 - SP1
    Domain: tkdsoftware.com

    Security Profile #2 - SP2
    Domain: petsutopia.com

    Security Profile #3 - SP3
    Domain: [nothing]

    Underwebserver you would have a configuration like so under redirect .. [domain]

    Entry One : default
    domain : tkdsoftware.com
    conf : Private E-mail [01]
    compute: <default>


    Entry Two : second
    domain : petsutopia.com
    conf : Private E-mail [04] <-- This is a different conference/public private whatever
    compute: <default>

    ///////////////////////////////////


    The logic works a little differently here

    When some one comes to petsutopia.com the webpath that is defined in the Conference Path Section is used for the root directory, which for example would be conference 04 path setup.

    If some one comes to the IP address the default setting is used and you will be redirected to tkdsoftware.com setup. Now the cool thing if this was setup, when a users logs in.. His current conference can be used for the path or a setting could be flaged or passed (http://tkdsoftware.com/login?
    changeconf=04) and the petsutopia.com could then be used.

    wcConfig could be setup to either change current conference based on domain (default) or to use current conference depending.

    I hope everyone follows because I think that builds on what is already here.

    I'll try and come with a better write up but what do you guys think?

    -Luke






    On 4/12/04 11:14 PM, CHRIS CRANFORD wrote to HECTOR SANTOS:

    Hector -

    I wanted to bring this up before I forget what I was thinking earlier
    today about this... and get your opinion and others as well because I
    am not sure what the goal is in order to offer this.

    But with that in mind, lets assume for the moment we take a multiple
    phased approach. I'm coming from the mind-set that the demand is to
    be able to have multiple WCWEB domains point to different WWWROOT directories.

    So, lets assume the following setup similar to things here:

    Security Profile #1 - SP1
    Domain: tkdsoftware.com

    Security Profile #2 - SP2
    Domain: petsutopia.com

    Security Profile #3 - SP3
    Domain: [nothing]

    Now, as the web server stands today, we have:

    wc:\http\public
    wc:\http
    wc:\http\template

    These are the major player directories.

    Now, could WCWEB be capable of reading the HTTP 'Host' header if it is passed and do a lookup against the domains defined in all the security profiles?

    If so, then could the following logic be implemented:

    Request: http://www.petsutopia.com (not authenticated)

    1. WCWEB sees that the session isn't authenticated and the URI is not
    referring to a protected document, so the request gets sent to
    http://www.petsutopia.com/public/

    2. WCWEB sees the wc:\http\public\default.htm request come in and it
    checks the web root folders in the following order:

    Check Host Header wwwroot directory if exists
    wc:\http(petsutopia.com)\public -->
    wc5\wwwroot\petsutopia.com\public

    Check Computer Config wwwroot directory if exists
    wc:\http(tkdsoftware.com)\public -->
    wc5\wwwroot\tkdsoftware.com\public

    Fall back to original logic
    wc:\http\public -> wc5\http\public

    3. When user logs into the web server, requests for protected
    documents would follow a simliar pattern:

    wc:\http(petsutopia.com)\default.htm ->
    wc5\wwwroot\petsutopia.com\default.htm
    wc:\http(tkdsoftware.com)\default.htm ->
    wc5\wwwroot\tkdsoftware.com\default.htm
    wc:\http\default.htm -> wc5\http\default.htm

    4. When templates are requested, simliarly:

    wc:\http(petsutopia.com)\template\XXX.htm ->
    wc5\wwwroot\petsutopia.com\template\XXX.htm
    ...
    wc:\http\template\XXX.htm -> wc5\http\template\XXX.htm

    I know that when (or if we) get to this point to do this, it is going to
    be a BIG change and require loads of testing ... Not sure when you have this slated on the project timeline, but since this idea came to my
    head, I certainly wanted to pass it along to you.

    Just to recap, for non-authenticated sessions, the host header would be
    used to initially determine the wwwroot directory path. If that path
    does not exist, try the domain for the computer running wconline. If
    that path does not exist, default to the current directory logic.

    For authenticated sessions, we could just use the security profile
    domain to determine the web root directory path instead of then relying
    on the host headers (unless you want to always carry this thru
    regardless).

    Anyways, gonna grab some TV.. Chat soon.

    Thanks,
    Chris



    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)