I was trying to figure out the jetty doc on the HTTP Trace and Track but could not find much. Is this statement true - "HTTP trace is disabled by default, but for embedded it is still enabled. " ? If it is, can someone please share the embed jetty doc link on how to disable it?
Thank you
First, there is no "Track" method.
When using a WebApp, aka a WAR file (or exploded WAR file), the default descriptor will disable the HTTP TRACE method.
This is true for Standalone Jetty, and Embedded Jetty.
If you want to enable the TRACE method, you have to supply a custom default descriptor to the WebApp that wants to honor the TRACE method. (Using the WebAppContext.setDefaultDescriptor(String) method in embedded, or in XML)
If you are using something that isn't a WebApp (eg: a Handler, a ScopedHandler, a ServletContextHandler, etc) then you have no restrictions on TRACE method usage.
Once you have TRACE enabled, it's up to your chosen web library to answer that method, as Jetty itself will not participate with production of the TRACE response.
Related
I am new in the area of SOAP Based web services. I am using TomEE server. The server is a bit customized according to my organization's need.
Few days back, when I was trying to run the web services example from TomEE website, I was able to generate the wsdl and calling the web service by a client.
Now, when I need to use the customized version of TomEE plus (by the organization), I can see that the request does reach to the server and hence there is a log entry also but my #WebMethod is not getting executed.
Does any one has any idea about any configuration which can prevent the request from reaching to the webservice method? Is there any pointer around how can I debug further to reach out to the root cause of this issue?
Without further information about what is customized it's like fishing in the dark.
I would guess that perhaps the global web.xml or the server.xml of tomee server is changed so that some URI context mappings are not forwarded or ignored. But it's only a lucky tip.
We would like to know which IP called our CF8 SOAP webservice (powered by Axis 1) and which method are being invoked. IIS log only shows POST from local IP. How can I enable logging for published SOAP webservices?
Thanks
There is a function, isSoapRequest, that determines if a CFC is being called as a web service. You could use that and if true, then log.
Sadly, Henry, There is no such logging, built-into CF.
I thought by your subject you were referring to outgoing web service calls (from within CFML), which since 9.0.1 are indeed logged (whether you do a CFINVOKE or CFOBJECT call), including the URL (but not the method) in the webservice.log.
But you want to log incoming calls to CFCs serving as web services, and there is no built-in logging for those. Not even in good ol' FusionReactor (which logs many things CF does not).
This would be a good thing, so I'd suggest you file a feature request. Until then, it would be incumbent upon you to do your own logging within your CFCs, using CFLOG to capture that useful info you seek.
You may even want to write it up as a method that others could reuse (and who knows, if you look around, maybe you'll find someone else having already done it).
I am not a PEGA developer. But this question is for any PEGA developer/admin. This is about an issue which I noticed recently while trying to integrate my application (using REST service) with PEGA 7.
I created a REST service from my application and hosted it with OAuth 2.0 authentication. PEGA application has to consume my service.
To test the connectivity from PEGA to my application, I'd created an OAuth token myself and shared the same with PEGA developers asking them to call my service directly by skipping the authorization calls.
Using any REST testing tool such as Chrome's REST console, APIgee, etc., I was able to test my REST service by just passing the http-header param as [param name: Authorization & param value: OAuth ].
But PEGA had an issue in directly supplying the http-header parameter to test my service from PEGA PRPC application.
My Questions for PEGA developers/Admins are,
is it difficult from PEGA to add a header param in http calls
On request, PEGA screen was shared with me while a developer attempted to test my service from PEGA. During which I noticed that PEGA did not have any trace logs to
capture the exact http request that was generated. Is it true that we could not see the http request (header/body) that was generated from the REST connector tool?
Adding a header parameter is relatively simple. To get information from a REST API in PEGA you define a Connect-REST rule. Sadly, I don't have enough reputation to post images in my answer but I uploaded a shot of the headers area to imgur which you can see here http://imgur.com/vWBm6dD. Make sure you tell your PEGA developers choose "Constant" as Map From and put the token in quotes in the "Map From Key" field like I did in the image.
Unfortunately, it is not possible to log the complete outgoing packet. If you set the logging level to DEBUG for the activity Rule-Connect-REST.pyInvokeRESTConnector it log a lot more information during the connection process, including the complete outgoing URL, but not the headers. For your PEGA developers, to change the logging level of this activity go to the Main Menu (click on DesignerStudio) -> System -> Tools -> Logs -> Logging Level Settings. There set the logger name to "Rule_Obj_Activity.pyInvokeRESTConnector.Rule_Connect_REST.Action" and the level to DEBUG.
If that's not enough to solve the problem your PEGA developers do have the option of adding in their own logging. Connector rules in PEGA are invoked rather than assembled, the code that creates the packet and makes the call to the remote service is in step 5 of that activity, pyInvokeRESTConnector. That activity can be private checked-out like any other so you could add in your own custom logging to make sure everything is being set up correctly there. However I would strongly advise them against overriding that activity in an application ruleset. Private checkouts are temporary so they are fine but an override is permanent and will also override all future updates if they decide to upgrade to another version of PRPC.
You could use the Tool Fiddler to see what exactly goes out of Pega to invoke your service.
For OAuth Authentication , make sure the Pega Authentication Profile is set to OAuth and the token is extracted properly.
Fiddler will help you see whats going on.
Now I want to prefix this with I am unsure whether this should be here or on server fault so I'll post it here to begin with.
We are developing a REST API in Coldfusion 9 which is being hosted on IIS 7 for a client which on certain calls must call another internal webservice. When making these calls from the server that the API is hosted on there are no errors, however when we make the call from a remote machine the following message is returned:
'connection failure. status code unavailable.'
I have googled the issue where the following was suggested as a fix http://www.talkingtree.com/blog/index.cfm/2004/7/28/20040729 but it does not work for me. The following are the notes from my own testing:
The calls which are causing the issue are a mix of get, put, post and delete.
The only common part of each call is the talking to the same webservice.
I am able to call the webservice directly from the places where I make the remote calls to the API from.
While all the calls make a call to the same webservice they do not all make the same call to the webservice.
Ideas:
Call the web service remotely using a URL that resolves to the internal ColdFusion server (e.g. http://[servername]:8300). You will probably have to some configuration to get this working. Reason for doing so is to identify if IIS or ColdFusion is the root cause. If you can hit the internal server remotely then IIS is probably the issue.
Is the web service call over SSL? If so, is remote caller also ColdFusion? If you've answered both yes, check to see if the SSL certificate is trusted by the remote caller's JVM. If not, you need to register it as part of the JVM's keystore.
Can you ping the host server from the caller? If not, does the caller need a "hosts" entry?
If enabled on your host, review the .NET filter and how it interacts with HTTP calls. I've experienced a situation where I was unable to access a folder called "/bin" because the .NET filter intercepted the requests.
The issue turned out to be that each of the calls required basic authentication which the calls themselves were handling, however basic authentication had been turned on in IIS which was causing IIS to intercept any requests with an Authorization header.
This causes an issue as IIS assumes that if authentication is passed up then it is for a user on that machine/domain and would reject any other credentials (which were valid for the system). It was working when we were logged into the machine because it was coming locally it did not need to authenticate the user.
I have a FinalBuilder project where I deploy an ASP.Net website to a remote folder, configured as a website in IIS.
As part of my build script, I want to use the FinalBuilder action HTTP Get File to help determine whether my deployment was succesful.
I'm having difficulty, because the website is configured (under IIS 6) to use Integrated Windows Authentication, and anonymous access is not enabled.
Now the HTTP Get File action, has only a handful of properties, one of which is a security section, containing a UserName and Password. Great I thought! I can just put some valid credentials in there, which FinalBuilder will impersonate, whilst retrieving my file.
It turns out I was mistaken. I receive the following error:
Error retrieving url : Socket Error # 10061
Connection refused.
If I run the action without setting the Security Username and Password, I get the following error:
Error retrieving url : HTTP/1.1 401 Unauthorized Response Code : 401
Here are some facts to help with the context of my problem.
I'm running FinalBuilder 6 Professional, upon a Windows Server 2003 installation, and deploying my ASP.Net website to a remote IIS6 server within our corporate LAN.
If I configure IIS on the remote server to allow Anonymous access, I can run the HTTP Get File action without error. However, running this particular site with anon access is not acceptable in our situation.
Can anyone help suggest a workaround?
For a definitive answer, I think the Finalbuilder Forum is probably your best bet.
My guess, though, is that the HTTP library used by FB doesn't support Windows authentication, and is failing because no common authentication method can be negotiated. Since HTTPS isn't supported either by the 'HTTP Get File action', the possible workaround of allowing basic authentication on your site isn't a good idea, as you would be passing credentials over the network in plain text.
The only remaining workaround I can think of (other than waiting for a future FB release), is creating your own FB action to retrieve the file. Using the .NET Framework System.Net.WebClient, that should be trivial. Just start with a standalone EXE to make sure everything works, then refactor it into a 'real' action using FinalBuilder Action Studio (if that's even required: spawning an external EXE may work just fine in your case).