I'm using Websphere Portal and trying to make an AJAX request via the Proxy but getting 404 status code.
When I issue the request below with my custom headers set I get 404:
GET http://proxy.com:10039/wps/proxy/https/server.com/cart/#self
But if I issue the same request not routed through the proxy, I get 200
GET https://server.com/cart/#self
Why is the proxy removing my headers?
I logged all headers on target server and see that the headers are actually removed when they pass through the proxy:
{accept=*/*, accept-encoding=gzip,deflate,sdch, accept-language=en-US,en;q=0.8, cache-control=no-cache, connection=keep-alive, host=server.com, pragma=no-cache, user-agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36}
Here is my proxy config:
<policy url="{$digital_data_connector_policy}" basic-auth-support="true" name="digital_data_connector">
<actions>
<method>GET</method>
<method>HEAD</method>
<method>POST</method>
<method>DELETE</method>
<method>PUT</method>
</actions>
<headers>
<header>User-Agent</header>
<header>Accept*</header>
<header>Content*</header>
<header>Authorization*</header>
<header>Set-Cookie</header>
<header>If-Modified-Since</header>
<header>If-None-Match</header>
<header>If-Unmodified-Since</header>
<header>X-Method-Override</header>
<header>Set-Cookie</header>
<header>MyCustomToken</header>
<header>MyCustomTokenPart2</header>
</headers>
<meta-data>
<name>forward-http-errors</name>
<value>true</value>
</meta-data>
<meta-data>
<name>forward-credentials-from-vault</name>
<value>true</value>
</meta-data>
</policy>
My changes to proxy-config.xml where not picked up until the update-outbound-http-connection-config task was run.
Related
I create a jmeter http request
with parameter name & value.
While the test result is no value only the parameter names.(parameter names are wrong :(
parameters config
error result
POST http://localhost:8080/aqnu/loginsys
POST data:
200117003200117003
Cookie Data:
JSESSIONID=438A7FCE7211763AFFF57F89F5A9FCB3
Request Headers:
Connection: keep-alive
Referer: http://localhost:8080/aqnu/login
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7
Origin: http://localhost:8080
DNT: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Cache-Control: max-age=0
Accept-Encoding: gzip, deflate, br
It might be the case with the parameters themselves, i.e. if you copied and pasted them from some source the parameters may include non-printable special characters like line breaks therefore JMeter fails to properly parse them in HTML mode. Try switching to Raw and see how does your request look like there
If the cause is different unfortunately we will not able to help without seeing the logs. If you want to check it out yourself or update the question with the logs:
Add the next lines to log4j2.xml file
<Logger name="org.apache.jmeter.protocol.http" level="debug" />
<Logger name="org.apache.http" level="debug" />
<Logger name="org.apache.http.wire" level="error" />
These lines will increase JMeter logs verbosity for HTTP protocol
Restart JMeter to pick up the changes
Search for your request parameters in jmeter.log file an see how do they look like.
HttpMonitor Config was working fine with tomcat7 and http service was getting detected however as we have updated to tomcat 8.5 http service is not getting discovered unless we set connector properties as sendReasonPhrase=true, the difference in the curl response is like below in compare to tomcat7 and tomcat 8.5 (withoutsend Reson Phrase parameter set)
tomcat7 gives ok in its header and tomcat8.5 does not.
however option for sendreson phase will be deprecated and removed from tomcat9 and even this option will not be available (https://tomcat.apache.org/tomcat-8.5-doc/config/http.html)
I am not sure why httpMonitor in openNms is not able to detect the http service even the snmpwalk output see port 80 available (both with and without send reason phrase)
in poller-configuration.xml looks like below for http
<service name="HTTP" interval="300000" user-defined="false" status="on">
<parameter key="retry" value="1"/>
<parameter key="timeout" value="3000"/>
<parameter key="port" value="80"/>
<parameter key="url" value="/"/>
<parameter key="rrd-repository" value="/var/lib/opennms/rrd/response"/>
<parameter key="rrd-base-name" value="http"/>
<parameter key="ds-name" value="http"/>
</service>
even we tried setting
<parameter key="response-text" value="~\bOK\b"/>
and
<parameter key="response" value="200"/>
however it did not help, i guess above parameter play its role once service got discovered however the problem here the service is not getting discovered (unless SendReson pharse is turn on ) it will only detect http service in tomcat 8.5 if we have sendreson phase turn on in connector definition inside server.xml
Kindly help to understand this behaviour here and possible solution for this without any change on client side.
openNms version info:
I have an API on which I have to enable only TLSv1.2 . Following is the configuration I have where i have set enabledProtocols="TLSv1.2".
<http:listener-config name="HTTPS_api-httpListenerConfig"
protocol="HTTPS" host="0.0.0.0" port="${https.port}"
doc:name="HTTP Listener Configuration">
<tls:context enabledProtocols="TLSv1.2">
<tls:trust-store insecure="true" />
<tls:key-store type="pkcs12" path="${keystore.pkcsstore}"
alias="${keystore.alias}" keyPassword="${keystore.password}"
password="${keystore.password}" />
</tls:context>
</http:listener-config>
Now when I deploy it in my local and try to consume it with the following client it works fine . unfortunately , when i deployed the same in cloudhub and try to consume it, its giving me following error even though i have explicitly set TLSv1.2 to use from client:
SSL handshake error: Client requested protocol TLSv1.1 not enabled or not supported
request config :
<http:request-config name="HTTP_Request_Configuration_basicAuth"
host="testtlsversion.cloudhub.io" port="443"
doc:name="HTTP Request Configuration" protocol="HTTPS"
responseTimeout="9999999">
<tls:context enabledProtocols="TLSv1.2">
<tls:trust-store path="${alert.keystore.path}" password="${alert.keystore.password}" type="jks" insecure="true"/>
</tls:context>
</http:request-config>
TLS V1.2 is not supported in current version .
Answer Here :https://forums.mulesoft.com/questions/84103/how-can-i-enable-only-tlsv12-on-my-rest-api.html?childToView=84150#answer-84150
I'm trying to find out if anyone has succeeded in using the UrlRewriteFilter
availabe from http://tuckey.org/urlrewrite/ to do a 301 permanent redirect from
http to https in Apache Tomcat but I don't seem to be getting anywhere fast.
A number of people have asked the same question and AFAICS none have been answered
If I'm asking in the wrong place then maybe someone would be kind enough to 'redirect' me to the right place.
If it's not possible then perhaps someone could say so.
Thank you.
apache-tomcat-7.0.42
jdk1.8.0_77
CentOS Linux 7.2.1511
urlrewritefilter-4.0.3.jar
The 'standard' configuration as recommended by the tomcat docs is as follows
web.xml
<security-constraint>
<web-resource-collection>
<web-resource-name>Secure URLs</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
server.xml
<Connector port="80" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="443" />
<Connector port="443" maxThreads="150" scheme="https" secure="true"
SSLEnabled="true" keystoreFile="/opt/keys/tomcat.keystore"
keystorePass="*********" clientAuth="false" keyAlias="tomcat" sslProtocol="TLS" />
entering localhost in a browser results in redirection to https
checking this with curl we can see that this works as expected but we get 302 temporary redirect
root#sandbox:/tmp# curl -D /tmp/headers.txt -s http://localhost
HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Thu, 01 Jan 1970 01:00:00 GMT
Location: https://localhost/
Content-Length: 0
Date: Fri, 29 Apr 2016 18:24:47 GMT
However this is unnacceptable to Google who prefer a 301 permanent
Is it possible to use UrlRewriteFilter to achieve this end
The following rule results in a 302 even though I'm using to type="permanent-redirect"
everything else stays the same
<rule>
<name>seo redirect</name>
<condition name="host" operator="notequal">^www_example_com</condition>
<condition name="host" operator="notequal">^localhost</condition>
<from>^/(.*)</from>
<to type="permanent-redirect" last="true">https://www_example_com/$1</to>
</rule>
I have tried various different combinations with no luck presumably because Tomcat is redirecting after the filter has been applied
Has anyone actually got this to work so that we get a 301 instead of a 302
Thank You
My backend server returns HTTP 405 back to Apigee 4.23 (OPDK) for a particular request. However, the backend fails to set the "ALLOW" header that the standard says that a 405 response should include.
Instead of fixing my backend (due to some constraints on touching a long running code base), I would like to handle this scenario in my proxy TargetEndpoint Response flow and add the ALLOW header. However, it looks like Apigee 4.23 (OPK) wouldn't let me do this and it sends the following response back to client:
HTTP/1.1 502 Bad Gateway
Content-Type: application/json
Content-Length: 139
{
"fault":{
"faultstring":"Received 405 Response without Allow Header",
"detail": {
"errorcode":"protocol.http.Response405WithoutAllowHeader"
}
}
}
I followed the documentation regarding setting the "success.codes" property on the TargetEndpoint:
<HTTPTargetConnection>
<Properties>
<Property name="success.codes">405</Property>
</Properties>
<URL>https://my.backend.url</URL>
</HTTPTargetConnection>
Still getting same error. How do I solve this ?
Am using Apigee 4.23 (On Premises Deployment Kit)
HTTP.ignore.allow_header.for.405 is checked only at system level not for each proxy. Instead of treating 405 as success in the proxy, you can treat that as a fault and handle it in the fault flow.
<FaultRules>
<FaultRule name="defaultFaultHandling">
<Step>
<Name>AssignMessage-1</Name>
</Step>
</FaultRule>
</FaultRules>
Where in AssignMessage he can add Allow header and return the response to client.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="AssignMessage-1">
<DisplayName>AssignMessage-1</DisplayName>
<FaultRules/>
<Properties/>
<Set>
<Headers> <Header name="Allow">GET, PUT</Header> </Headers>
</Set>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<AssignTo createNew="true" transport="http" type="response"/>
</AssignMessage>
You can use the success codes property in the following way.
Also we do not have an equivalent property for HTTP.ignore.allow_header.for.405 for Target Endpoint.
Test
Instead of using the below
<HTTPTargetConnection>
<Properties>
<Property name="success.codes">405</Property>
</Properties>
<URL>https://my.backend.url</URL>
</HTTPTargetConnection>
Use the below and let me know if it works or not:
<HTTPTargetConnection>
<Properties>
<Property name="additional.success.codes">405</Property>
</Properties>
<URL>https://my.backend.url</URL>
</HTTPTargetConnection>
I could handle this using a flow CatchAll as the last flow in Flows
<Flows>
<!--
...
-->
<Flow name="CatchAll">
<Request>
<Step>
<Name>raiseMethodNotAllowedFaultResponse</Name>
</Step>
</Request>
<Response/>
</Flow>
</Flows>
The correspondig raise fault policy
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="raiseMethodNotAllowedFaultResponse">
<DisplayName>raiseMethodNotAllowedFaultResponse</DisplayName>
<Properties/>
<FaultResponse>
<Set>
<Headers>
<Header name="Allow">POST</Header>
</Headers>
<Payload contentType="text/plain">Method Not Allowed</Payload>
<StatusCode>405</StatusCode>
<ReasonPhrase>Method Not Allowed</ReasonPhrase>
</Set>
</FaultResponse>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>