Proxy config for cross site Ajax (JSON) calls in Websphere Portal 7 - ajax

First off, I'm new to portal development in general, and thus have no previously experience with Websphere Portal. Note: URLs have been changed to protect the innocent.
I have a portlet on Websphere Portal 7 where I'm trying to make an Ajax call (a POST in this case) to another server. I know I have to create the proxy-config and wire up the ProxyServlet so Portal will allow the cross site ajax call, and I have done that. However, I'm getting a 403 Forbidden message when calling the proxied service.
Here's my proxy-config.xml:
<proxy:proxy-rules
xmlns:proxy="http://www.ibm.com/xmlns/prod/sw/ajax/proxy-config/1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<proxy:mapping contextpath="/proxy" url="*"/>
<proxy:policy acf="none" url="*">
<proxy:actions>
<proxy:method>GET</proxy:method>
<proxy:method>POST</proxy:method>
</proxy:actions>
</proxy:policy>
<proxy:policy acf="none" url="https://subdomain.domain.org/ss/services/*">
<proxy:actions>
<proxy:method>GET</proxy:method>
<proxy:method>POST</proxy:method>
</proxy:actions>
</proxy:policy>
<proxy:meta-data>
<proxy:name>max-connections-per-host</proxy:name>
<proxy:value>5</proxy:value>
</proxy:meta-data>
<proxy:meta-data>
<proxy:name>max-total-connections</proxy:name>
<proxy:value>100</proxy:value>
</proxy:meta-data>
</proxy:proxy-rules>
Here is the ProxyServlet in web.xml:
<servlet>
<servlet-name>ProxyServlet</servlet-name>
<servlet-class>com.ibm.wps.proxy.servlet.ProxyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/ss/services/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/proxy/*</url-pattern>
</servlet-mapping>
And here is the URL that I'm attempting to call from javascript (via jQuery):
"wps/proxy/https/subdomain.domain.org/ss/services/service1"
I'm currently getting 403 Forbidden "The URL you tried to access through the proxy is not allowed" error message. And this is the URL Firebug shows the portlet is hitting (seems to be correct):
http://portalsubdomain.domain.org:77777/wps/proxy/https/subdomain.domain.org/ss/services/service1.
Based on the proxy docs for wp7, I know 403 means one of the following:
The request was not accepted by the proxy, that is the proxy found no matching access policy that grants access to the target server.
Basic authentication failed.
It should've found the proxy policy since I have it defined for all URLs, so what am I missing? I'm figuring I either haven't configured the proxy policy correctly (authentication?) or I haven't constructed the URL in the JSON call correctly. I reviewed the format "rules" but haven't been able to come up with a solution that works.
A couple of things to note:
This portlet is on a child page of another page, and dojo is part of a custom theme we created
We are using LDAP to log into the portal, so not sure if that makes any difference as well. I'm logging in with portal admin rights when running this.
The URL for the page where the portlet is being loaded (and thus the page/space structure) is http://portalsubdomain.domain.org:77777/wps/demoportal/home/demo/ajaxTest. Not sure what the proxy is looking for, but the proxy-config.xml is located within my portlet's WEB-INF folder.
If I change the URL in my JSON call to wps/demoportal/home/demo/ajaxTest/proxy/https/subdomain.domain.org/ss/services/service1, I get the HTML for the ajaxTest page in return.

Found the solution! I needed to get the context path of the portlet and prepend it to the service URL.
Since my service call is in a separate .js file (via JavascriptMVC & jQuery), my quick and dirty fix is to create a JavaScript variable on the .jsp in order to get the portlet context path like so:
var globalRequestContextUrl = "<%= renderResponse.encodeURL(renderRequest.getContextPath()) %>";
then in my ajax call, I prepend the context url to my call to the proxy like so:
globalRequestContextUrl + "https/subdomain.domain.org/ss/services/service1"
Now I'm fighting SSL certificate issues, but I'm definitely getting through the proxy now.

Related

AEM 6.5 (Apache Sling) /saml_login not running postProcessor

I have a protected page setup in AEM using the Authentication Requirement checkbox on the author. Then over in the OSGi I have config for my external Okta SAML config:
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:OsgiConfig"
identitySyncType="default"
keyStorePassword="admin"
service.ranking="5002"
idpHttpRedirect="{Boolean}false"
createUser="{Boolean}true"
defaultRedirectUrl="/"
userIDAttribute="ssoGuid"
idpIdentifier=""
assertionConsumerServiceURL=""
defaultGroups="[everyone]"
storeSAMLResponse="{Boolean}false"
signatureMethod="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
idpCertAlias="certalias___1657659258516"
addGroupMemberships="{Boolean}true"
path="[/content/mySite]"
digestMethod="http://www.w3.org/2001/04/xmlenc#sha256"
synchronizeAttributes="[...]"
clockTolerance="60"
groupMembershipAttribute="groupMembership"
idpUrl="oktaURL"
serviceProviderEntityId="https://stage.mySite.com"
logoutUrl=""
handleLogout="{Boolean}false"
userIntermediatePath="sso"
spPrivateKeyAlias=""
useEncryption="{Boolean}false"
nameIdFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
And in my okta config, I have https://stage.mySite.com/saml_login as the SSO URL and https://stage.mySite.com as the audience restriction.
When I navigate to the requested page in AEM I get redirected to Okta, I sign in and am redirected to https://stage.mySite.com/saml_login, all of this is expected, here is where it gets weird, I then get a 301 redirect to https://stage.mySite.com/saml_login.html which then gives a 404. It seems like AEM does not have a listener setup and so does the redirect.
Any thoughts on what i might have misconfigured?
In my case, it was a dispatcher config issue (or nginx, not sure where the rewrite was done).
It was setup to append '.html' if it does not exist in the requested url. I needed to make an exception for that rule.

Swagger page being redirected from https to http

AWS Elastic Load Balancer listening through HTTPS (443) using SSL and redirecting requests to EC2 instances through HTTP (80), with IIS hosting a .net webapi application, using swashbuckle to describe the API methods.
Home page of the API (https://example.com) has a link to Swagger documentation which can bee read as https://example.com/swagger/ui/index.html when you hove over on the link.
If I click on the link it redirects the request on the browser to http://example.com/swagger/ui/index.html which displays a Page Not Found error
but if I type directly in the browser URL https://example.com/swagger/ui/index.html then it loads Swagger page, but then, when expanding the methods an click on "Try it out", the Request URL starts with "http" again.
This configuration is only for Stage and Production environments. Lower environments don't use the load balancer and just use http.
Any ideas on how to stop https being redirected to http? And how make swagger to display Request URLs using https?
Thank you
EDIT:
I'm using a custom index.html file
Seems is a known issue for Swashbuckle. Quote:
"By default, the service root url is inferred from the request used to access the docs. However, there may be situations (e.g. proxy and load-balanced environments) where this does not resolve correctly. You can workaround this by providing your own code to determine the root URL."
What I did was provide the root url and/or scheme to use based on the environment
GlobalConfiguration.Configuration
.EnableSwagger(c =>
{
...
c.RootUrl(req => GetRootUrlFromAppConfig(req));
...
c.Schemes(GetEnvironmentScheme());
...
})
.EnableSwaggerUi(c =>
{
...
});
where
public static string[] GetEnvironmentScheme()
{
...
}
public static string GetRootUrlFromAppConfig(HttpRequestMessage request)
{
...
}
The way I would probably do it is having a main file, and generating during the build of your application a different swagger file based on the environnement parameters for schemes and hosts.
That way, you have to manage only one swagger file accross your environments, and you only have to manage a few extra environnement properties, host and schemes (if you don't already have them)
Since I don't know about swashbuckle, I cannot answer for sure at your first question (the redirect)

WebAPI SignalR Negotiate response different on different browsers

The main problem about Access-Control-Allow-Origin I think. But when I configure the Web API project as defined in the given documentation, it still not working in chrome and firefox but working in IE well (it is about IE thinks localhost is not cross domain, AFAIK). I tried different ways to make it work but no result.
I put the example project to github repository. Project is very simple. There are two applications working on cross domains. It is very simple chat application like in signalr examples.
You must change the value of api host in client javascript file:
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApp/Scripts/app/chat.js#L2
When you open the Chat page in mvc project, there will be two requests to api application
1- Regular ajax request (which is working fine)
2- Signalr negotiate request (cancelled)
And also I don't think browser disables the CORS because of if it disables there would not be an hit to server. So I think it is about browser but not about browser disables (something else).
Details are in repository
Readme: https://github.com/yusufuzun/WebApiSignalR/blob/master/README.md
Fiddler Results: https://github.com/yusufuzun/WebApiSignalR/blob/master/FiddlerResults
The bad part about it also is server returning 500 with this error:
System.InvalidOperationException: 'chat' Hub could not be resolved.
Which hub name is chat also.
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/Hubs/ChatHub.cs#L10
You can enable CORS for Web Api in project with different ways for test purposes. Each one is giving different errors all about XMLHttpRequest Access-Control-Allow-Origin.
I commented them, so you can uncomment and make test for each one:
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/Global.asax.cs#L24
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/App_Start/WebApiConfig.cs#L14
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/App_Start/WebApiConfig.cs#L16
https://github.com/yusufuzun/WebApiSignalR/blob/master/ChatApi/Controllers/ChatController.cs#L17
So what is going on here?
After I talked with David Fowler in JabbR, he mentioned the thing about using CORS with SignalR. My signalr startup code was wrong. So after changing the startup code like in his advice it worked well.
He also mentioned SignalR and Web API are working with different CORS definitions. So enabling or disabling one doesn't affect other.
Here is the new startup code:
app.Map("/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
map.RunSignalR(new HubConfiguration()
{
EnableDetailedErrors = true,
EnableJavaScriptProxies = true
});
});
The old one:
app.MapSignalR(new HubConfiguration()
{
EnableDetailedErrors = true,
EnableJavaScriptProxies = true
}).UseCors(CorsOptions.AllowAll);
Hope it helps to somebody out there.

tomcat+josso1.8.6+spring

I use JOSSO 1.8.6. I configure all in the Tomcat lib directory file related to JOSSO, and I'm also doing all configuration in web application[spring] WEB-INF file. I got the below URL.
http://localhost:8080/TestLogin/?josso_cmd=login_optional
&josso_back_to=http://localhost:8080/TestLoginDemo/josso_security_check
&josso_partnerapp_id=TestLoginDemo
But my question is:
My parent web application is --TestLogin means this application login page is main to display all the other web application [child web application].
I have 3 child application
TestLoginDemo
jossoLogin1
JossoLoginDemo
All are spring application.
I hit in browser mean URL is http://localhost:8080/TestLoginDemo
So the below URL I see
http://localhost:8080/TestLogin/?josso_cmd=login_optional
&josso_back_to=http://localhost:8080/TestLoginDemo/josso_security_check
&josso_partnerapp_id=TestLoginDemo
But after the successful login I find the TestLogin flow means not transfer to the TestLoginDemo.
So what is the way if I have to carry on flow for TestLoginDemo?
And; after success this URL:
http://localhost:8080/TestLogin/?josso_cmd=login_optional
&josso_back_to=http://localhost:8080/TestLoginDemo/josso_security_check
&josso_partnerapp_id=TestLoginDemo
login page I got below URL in success:
http://localhost:8080/TestLogin/login.htm
instead of the below correct URL:
http://localhost:8080/TestLoginDemo/login.htm
Could anybody guide me on how to achieve this?
Why josso_cmd=login_optional, did you set it up like this ? By default this is unecessary to specify the josso_cmd argument.
In order to get back to the original application, you have to use josso_partnerapp_ctx argument (don't forget to encode URL), this will be passed to the security check page that will lead you to this page if the security check is sucessfull
Usually, URL looks like this:
https://login.domain.com/josso/signon/login.do?josso_back_to=https://site.domain.com/Josso/Check&josso_partnerapp_host=site.domain.com&josso_partnerapp_ctx=https%3a%2f%2site.domain.com%2fhome.html

Spring MVC -> dependent on URL display welcome page

I have a Spring MVC application (version 3.0.5.RELEASE) and I have this in my mvc-config.xml:
<mvc:view-controller path="/" view-name="welcome"/>
So requests to "/" are forwarded to the welcome view welcome.jsp.
This means in my case, calling the URL http://myproject-test.mydomain.com/ will forward to the welcome.jsp. It's fine, but I have to extend it. Besides the URL http://myproject-test.mydomain.com/, I have the URL http://myproject-anothertest.mydomain.com/. With this URL, the whole application should be the same, except the welcome page.
Calling http://myproject-anothertest.mydomain.com/, I want to have the welcome-test.jsp page instead of the welcome.jsp.
So, how can I do this? I have to know from which subomain (myproject-test or myproject-anothertest) the user calls the site and then show him welcome.jsp or welcome-test.jsp.
Does anyone know how this can be done?
Thank you in advance & Best Regards, Tim.
The tag <mvc:view-controller> maps to ParameterizableViewController
You could inherit your own controller class from its parent, AbstractController, and use the request parameter in method handleRequestInternal to deduce which hostname is being used to access your page, then use the appropriate view.
HTTP request header Host contains (if using HTTP/1.1) the "virtual" server name that is being used to access your page. Older HTTP/1.0 protocol does not have the Host header, and some proxies map traffic to HTTP/1.0, in that case you will not be able to distinguish between the traffic using different names.
In JSP, you could use <%=request.getServerName()%> to access the Host header value. See doc for getServerName.

Resources