locked
UAG: Change/rewrite the URL Path RRS feed

  • Question

  • Hello

    We have a UAG RC0 setup with a internal sharepoint server. 

    Is it possible with a Portal OR a Basic trunk do the following with a request:
    http://www.abc.com (port 80) > [UAG] > http://extmoss:9000/sites/abc

    The vistor should not be aware that internally there is a site collection below a managed path - he/she should only see www.abc.com/pages/default.aspx as a welcome page and internally that corresponds to http://extmoss:9200/sites/abc/pages/default.aspx

    This is a anonymous site where we dont use any fancy sharepoint stuff, only basic publishing (we are aare that some part sof SharePoint (2007) does not support path rewrites.
    Wednesday, January 13, 2010 8:34 AM

Answers

  • Dennis,

    my 2 cents on your hypothesis...

    I'd find it slightly suprising if the Manual URL Replacement feature has any affect on SP published with newest template that supports AAM.   The whole point of the Manual URL Replacement feature is to tell IAG/UAG where to send a request when a request comes in with ni unigue signature.  For SP2007 on UAG, all requests for SP come in (and go out) with no signature, hence the public host name, and the AAM support.   My guess is that for your particular SP server, the SP itself is redirecting the request for / to a request for /sites/nss.   Try the same test with no manual url replacement rule to confirm.

    But lets suppose, for some crazy reason, the url replacement was getting invoked and was the cause of the request for /sites/nss.  You've now created a problem because a request for /Page.aspx and /Page2.aspx and every other request would get sent to /sites/nss.  Not what you want.   You'd need a separate more specific Manual Replacement rule for every sharepoint request that will ever get made.  Which in itself makes the solution unworkable, but lets say you did do this.   You still have a problem in that this only affects the inbound connections.  When SP responds to the client, the redirects or embedded links would remain in the /sites/nss/<something> format.  Which brings us back to the question I asked whether the point was to completely hide this the whole session or just on an initial request for /.  If for the whole session, you are out of luck.  If for just the initial request, and Manual replacement is oddly in affect for SP, then it could be a solution if the URL was / instead of /.*.  But you could easily do the same thing from postpostvalidate and cover your bases for multiple SP servers in there, as opposed to the Manual URL replacement which would only allow for one SP server on the trunk...

    Thanks,
    Mark

    MBR Security, Inc.
    IAG experts since 2002
    • Marked as answer by Erez Benari Friday, January 15, 2010 9:54 PM
    Thursday, January 14, 2010 8:09 PM

All replies

  • By default, UAG is not going to be doing any translation on the path.   So the following is possible:

    http://www.abc.com/sites/abc (port 80) > [UAG] > http://extmoss:9000/sites/abc


    Though (and forgive my ignorance on the Sharepoint side with the exception of standard AAM rules for standard IAG/UAG connectivity), I think your general desire may be able to be acheived by a combination of what UAG does by default, and what Sharepoint is capable of by default.

    Wednesday, January 13, 2010 2:51 PM
  • The problem is that we want to hide a interna complex url with a more SEO friendly url on the outside without having to create lots of web applications on the Sharepoint farm.

    Like this:
      http://www.abc.com > http://extmoss:9000/sites/abc
      http://www.def.com > http://extmoss:9000/sites/def
      http://www.ghi.com > http://extmoss:9000/sites/ghi

    All on the same sharepoint web application (port 9200)


    It seems that the reverse proxy support some kind of rewriting because when using a Portal Trunk it gives this:
    http://www.xyz.com/uniquesig12571754dc8f443b5e582f81f379bd8c/uniquesig0/sites/xyz/Pages/default.aspx > http://extmoss:9000/sites/xyz

    And if the software can remove /uniquesig12571754dc8f443b5e582f81f379bd8c/uniquesig0/ from the request and add it back to the response it seems possible that the finctionallity is there somewhere.
    Thursday, January 14, 2010 9:51 AM
  • The uniquesig part of the URL you are referring to is part of the HAT feature.  Its how UAG can acheive a one-many scenario wherreby one external url can be destined for many backend webservers.   HAT is not going to help with what you asking, and in fact, the newest SP2007 application template (late version of IAG, and in UAG) does not even use HAT.  UAG knows which webserver to send the request to by the uniquenes of t he URL, or in UAG terms, the "public hostname" used.  Each public hostname for SP2007 and also for "Other web application (application specific hostname)" maps one-to-one with a backend RWS, and the path is left completely only. 


    If we are talking about an initial one-time thing where you want www.abc.com to really go the sharepoint site http://extmoss:9000/sites/abc then you can probably easily achieve this thru some combination of a postpostvalidate script, and also the settings on the portal link tab in the applications properties of the SP2007 published app in UAG (maybe including startup script).   However from that point on, the user will see www.abc.com/sites/abc/Page1.aspx.  But if you want the path hidden for the whole session and UAG to continually be doing some non standard translations on the URL to remove the /sites/abc part, then it may be possible, but good luck writing and maintaining the scipts to try and make it happen..

    Thursday, January 14, 2010 2:38 PM
  • Hi Niklas--

    Please try the following...

    Advanced Trunk Configuration >> Application Access Portal >> Manual URL Replacement

    URL:          /.*
    TO URL:     /sites/abc
    Server:     extmoss
    Type:        rerouting
    Port:         9200

    I just did a small test in my lab and it looks promising
    www.celestixlab.com  took me directly to internal url moss2007lab.celestix.com/sites/nss

    Thanks
    dennis
    Thursday, January 14, 2010 7:13 PM
  • Dennis,

    my 2 cents on your hypothesis...

    I'd find it slightly suprising if the Manual URL Replacement feature has any affect on SP published with newest template that supports AAM.   The whole point of the Manual URL Replacement feature is to tell IAG/UAG where to send a request when a request comes in with ni unigue signature.  For SP2007 on UAG, all requests for SP come in (and go out) with no signature, hence the public host name, and the AAM support.   My guess is that for your particular SP server, the SP itself is redirecting the request for / to a request for /sites/nss.   Try the same test with no manual url replacement rule to confirm.

    But lets suppose, for some crazy reason, the url replacement was getting invoked and was the cause of the request for /sites/nss.  You've now created a problem because a request for /Page.aspx and /Page2.aspx and every other request would get sent to /sites/nss.  Not what you want.   You'd need a separate more specific Manual Replacement rule for every sharepoint request that will ever get made.  Which in itself makes the solution unworkable, but lets say you did do this.   You still have a problem in that this only affects the inbound connections.  When SP responds to the client, the redirects or embedded links would remain in the /sites/nss/<something> format.  Which brings us back to the question I asked whether the point was to completely hide this the whole session or just on an initial request for /.  If for the whole session, you are out of luck.  If for just the initial request, and Manual replacement is oddly in affect for SP, then it could be a solution if the URL was / instead of /.*.  But you could easily do the same thing from postpostvalidate and cover your bases for multiple SP servers in there, as opposed to the Manual URL replacement which would only allow for one SP server on the trunk...

    Thanks,
    Mark

    MBR Security, Inc.
    IAG experts since 2002
    • Marked as answer by Erez Benari Friday, January 15, 2010 9:54 PM
    Thursday, January 14, 2010 8:09 PM
  • Sorry to hear that the Reverse Proxy dont have support for path-rewriting (except for the built in HAT that does path-rewriting and also fixes the content sent back to the visitor). It should not be so hard implement (rewrite the incoming url and filter the outgoing html/css/js) so that it is strange that it is not available. (Apaches mod_rewrite fixes that).

    This means that if we have 40 unique domainnames we also need to have 40 different web applications (that not a good design) with different ports in sharepoint if we would like to keep a short and SEO friendly url or implement the rewriting down on the sharepoint/webbapp level or put a second reverse proxy in between.

    Please stop mark everything as answers when they are only replies in a thread. A answer should give a suggestion on how so solve a problem, not saying that everything is impossible or stupid to do.
    Thursday, January 21, 2010 12:26 PM