CA Service Management

  • 1.  CA Unified Self Service - Absolute URL's vs Relative URL's

    Posted Feb 01, 2017 07:00 AM

    Hi,

     

    We are currently facing this issue with CA USS at a customer.

    I would like to know if anyone has faced this issue before and was there a way around it.

     

    As we all know CA Unified Self Service is based on Liferay and uses Tomcat to deploy the CA USS application.

     

    When deployed with a reverse proxy or behind the Load Balancer in SSL offloading mode meaning client->LB in SSL and LB->liferay in non-SSL the URL is rewritten to "http" from "https" by the liferay. This causes issues with some Load Balancers if they do not rewrite the http to https. This can be addressed by setting "web.server.protocol" to "https". However, this makes it portal wide no matter if it is accessed via LB/RP or directly from local network. In the case of direct access from the local network, the URL will be rewritten to "https" which might break when the liferay is not setup with SSL (more likely not setup with SSL since the SSL is off loaded to LB). We need to be able to configure the "webserver." set of parameters per network.

     

    Maybe a solution request would be?

     

    The Absolute URL inserts the domain in links where it can sometimes be undesirable. A Relative URL will show the correct context path regardless of domain. As an example both Both CA Service Catalog and CA Service Desk manager works in this. 


    The following implementations on liferay could address this;
    1) Stop using Absolute URLs altogether. This would solve a ton of security issues, simplify the code, and ensure that the code works regardless of the environment.
    2) Create a portal property that allows Relative URLs to be used instead of Absolute URLs. With a portal property you could simply change the method above to return an empty string if it is set to use Relative URLs.

     

    Thank you.

    Cornel Kleynhans



  • 2.  Re: CA Unified Self Service - Absolute URL's vs Relative URL's

    Broadcom Employee
    Posted Feb 01, 2017 02:34 PM

    Cornel,

     

    As you have indicated that its an all or nothing situation, do you think an alternative would be to host two separate nodes, one for internal usage with http   and other external using https?

     

    _R



  • 3.  Re: CA Unified Self Service - Absolute URL's vs Relative URL's

    Posted Feb 02, 2017 02:53 AM

    HI Ragu,

     

    No not really. This will mean that the one node will respond on HTTPS and this is against the customer standards.All internal communications should be over HTTP. 

    Also, this will mean that we need to hardcode the HTTPS response in the web.server.protocol. 

     

    Ideally, USS\Liferay should be able to use Relative URL's. This will resolve the Mix Content errors connecting through the Internet.

     

    Regards,

    Cornel



  • 4.  Re: CA Unified Self Service - Absolute URL's vs Relative URL's

    Broadcom Employee
    Posted Feb 02, 2017 12:26 PM

    I totally understand.


    As indicated in your original posts, there were several discussions on Liferay forums about how people got their configurations working with the usage of anchors, but none of them appear to be concrete.

     

    Unfortunately I do not have any other ideas at this time.

     

    Having said that, a mixture of HTTP and HTTPS will always give trouble. That's something to keep in mind... its better to make everything HTTPS to avoid mixed content issues

     

    _R



  • 5.  Re: CA Unified Self Service - Absolute URL's vs Relative URL's

    Posted Feb 06, 2017 02:37 AM

    Hello Raghu,

     

    Thank you for your response.

     

    Even though your answer and design is practical in theory not all customers will agree to this approach.

    This is why the application should work on relative URL's (like all the other Service Management products) and not on absolute as it does right now. This will then cater for a broader customer base with complex architectures. 

     

    I strongly believe we have a real problem here and that CA should address this asap. 

    Surly this can't be a unique customer situation? 

     

    Cornel