I have a Spring-WS web service (SOAP 1.2 MTOM) deployed as part of a large application (on Weblogic) returning incorrect Content-Type (Consumer doesn't like it). The Content-Type is
Content-Type: multipart/related;boundary="----=_Part_1_4569975.1498510764791";type="text/xml";start="<soapPart>"
I have another lean model service that I have deployed on TomEE returning it this way (Consumer likes it) -
Content-Type: Multipart/Related; boundary="----=_Part_4_1924421953.1498510734751"; type="application/xop+xml"; start-info="application/soap+xml"
What could be wrong on the first service. Where is the configuration that ensures the right Content-Type?
Update (after 5 days) -
I have narrowed it down to the same exact WAR file returning content-type "text/xml" on Weblogic (10.3.6) and "application/xop+xml" on TomEE 1.7.4. Anyone can tell me what could be the difference between these environments? How can I make the application return the right content type on Weblogic?
The difference between these two environments will be the SAAJ implementation. TomEE will likely use the one in the JRE, while Weblogic has its own SAAJ implementation. Instead of using Spring-WS with SAAJ, you may want to try configuring it with Axiom.
Related
I have already configured Keycloak role based access control with my java API project and it is deployed with Wildfly and runs without any errors. Since I have tested and confirmed the responses with Postman, I needed to use Swagger in-order to generate API documensts.
Using Swagger Inspector I created an API definition and exported that via SwaggerHUB to use it in SwaggerUI which I run locally. With web-origins and all the necessary steps configured in Keycloak and with authentication parameters set in Swagger script, I get the below error..
"
Access to fetch at (api request) from origin (swagger ui path) has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
"
I have noticed that if I bypass Keycloak, this works. What might be the best solution to overcome this issue?
I was able to resolve my issue referring this answer. I too added "enable-cors": true in keycloak.json in my Java back-end server which was Wildfly and tested the same implementation in server environment successfully.
I installed TFS 2017 to be accessible on both, HTTP (port 8080, default settings) and HTTPS. Now I removed HTTP binding form the IIS and reapplied the Public URL (via Administration Console -> Change Public URL).
Most of the TFS application tier works normally (as it uses relative addressing). However, build extensions somehow want to get their icons from HTTP (port 8080). See screenshot. When I noticed this, I first checked the HTML/JS source and I found that _vssPageContext variable still holds some URLs pointing to old HTTP configuration.
Has anyone solved that mistery or has any idea what to do?
EDIT: Later I re-enabled the HTTP bindings in IIS just to make the TFS work and I get a lot of warnings and errors due to HTTP / HTTPS mixup (I access TFS via HTTPS, however some content is still accessed via HTTP):
Mixed Content: The page at
'https://xxxx.xxxxx.xxxx/tfs/TFSDefault/Project/_build/definitionEditor?definitionId=113&_a=simple-process'
was loaded over HTTPS, but requested an insecure image
'http://xxxx.xxxxx.xxxx:8080/tfs/TFSDefault/_apis/distributedtask/tasks/9fcb05af-0ffe-4687-99f2-99821aad927e/0.1.1305/icon'.
This content should also be served over HTTPS.
WebSocket connection to
'ws://xxxx.xxxxx.xxxx:8080/tfs/signalr/connect?transport=webSockets&clientProtocol=1.5&contextToken=412c3608-de3b-4dab-a00d-bf5c13728d97&connectionToken=OoSymcl1qzWg%2BrHB9pzSBpb%2BdHVywo7NNUWN5xMx3Z51p9ZdZQ14wvoQKXqxB%2Bvo66eTap4iUdlqzHR1hJNUf%2By8oFUaudlkCbQIZjHQhLBHsEWtcLdfLlL7MAevl4h0My1yQA%3D%3D&connectionData=%5B%7B%22name%22%3A%22builddetailhub%22%7D%5D&tid=7'
failed: HTTP Authentication failed; no valid credentials available.
This is an issue related to the default endpoint of TFS being initially set as http, which all the elements are then defaulting their requests to, rather than relying on the initial request you are making in the browser. so you end up with a javascript element attempting to connect to the server via http and get a cross content issue.
Here is a really good article that covers the issues you are probably facing and how to fix them to use https: https://hybriddbablog.com/2017/12/16/changing-tfs-to-use-https-update-your-agent-settings-too/
I have to caveat that I havent done this yet, we actually went back in favour of running http until we moved to the next version of TFS, but from my experience of TFS, the steps look sound.
I'm currently creating an application, in which I use code like this:
session.user = user.username
Hence I get JSESSIONID cookie created. But I want my client side program to read this cookie; But since its been set HttpOnly to true I can't get value from client side.
How one should change the cookie Httponly to set false in grails? So that client side code can read them?
Thanks.
The httpOnly setting isn't a Grails option but rather an option of the container running your application (Tomcat in your example). Thus these changes are going to be related to Tomcat more than Grails.
Normally Grails creates the web.xml for Tomcat at compile/runtime and while you could use the eventConfigureTomcat within BuildConfig.groovy to configure Tomcat, this would only work for development and testing environments and not production.
Thus, it's best to use install-templates and modify your src/templates/war/web.xml to have the correct value for the httpOnly attribute. e.g. <Context httpOnly="false" ... You can find out more information about configuring Tomcat from their official documentation.
i use WCF with ios application, and when request for some method, IIS returns me 415 error, Not Supported Media Type.
Proxy class are generated through wsdl2objc, the same call from windows application works fine
The problem is probably in your WCF service configuration, specifically the binding you're using. I suppose you have configured it to use either custom binding or WSHttpBinding, but in either way the service expects application/soap+msbin1 mime type, but the requests made by the generated classes from wsdl2objc are with text/xml. I'm not quite sure how to fix it, but start by configuring your service for the standard BasicHttpBinding and give it a try. Also revert all changes you've made on the generated code from wsdl2objc.
Btw WSHttpBinding uses SOAP 1.2 and I'm not sure if wsdl2objc can work with it (i have tested it only with BasicHttpBinding).
In my ASP.NET MVC 2 app, I have the following lines:
Response.Cache.SetMaxAge(TimeSpan.FromDays(90));
Response.Cache.SetETag(lastWriteTime.Value.Ticks.ToString());
Using Fiddler to trace the HTTP streams, I can see:
ETag: 634473035667000000
in the Response Headers when running under IIS7, but when I'm running under the Visual Studio 2010 web server, this header just... disappears. Whether I set it via Response.Cache.SetETag() or via Response.AppendHeader("ETag", etag), it just never gets returned.
Is this a "feature" of the IIS web server? Is there some config setting I've missed? It's going to make testing cache invalidation a bit fiddly if I have to attach to the IIS process to be able to debug anything...
EDIT: It also appears that despite calling Response.Cache.SetCacheability(HttpCacheability.Public), VS/Cassini always returns resources with HTTP Cache-Control set to "private"... does that help?
The ETag will be suppressed if you use HttpCacheability.Private.
You can find more information on Why does HttpCacheability.Private suppress ETags?
If you change it to HttpCacheability.ServerAndPrivate it should work
Simple - it's Cassini.
Cassini isn't meant to be a production server, but is there to facilitate debugging (which is why it overrides caching too - after all if you recompile and rerun would you want your new code not touched because a page is cached?)
If you want your debugging to work as it would in IIS then IISExpress is where you should be going... there's no attach problem there as it will spin up a real instance of IIS, but in your own user context.