Disable /rest URL in ColdFusion10 - rest

Our problem with ColdFusion 10 is that there is the /rest/ URL binded. In our application we have a rest service ourselves. Since ColdFusion 10 it will not work because the URL is already defined and our requests won't get through. Is there any way to disable /rest/ completely? Or do we have to rename our service?
I also tried to edit the axis2.xml file
<parameter name="disableREST" locked="true">true</parameter>
<parameter name="restPath">restdisabled</parameter>
But that won't effect anything on the server.
Thanks in advance!

Disclaimer: I have not tried this and do not have a ColdFusion 10 installation nearby to verify
There is a servlet mapping defined in the web.xml file that defines how to handle /rest/ requests for ColdFusion. So you should be able to rename that URI to something else for your implementation. The web.xml file is located under the wwwroot\WEB-INF directory on your ColdFusion server.
I found some reference to this here - Getting started with RESTful web services in ColdFusion (under the Accessing a REST Service through HTTP section)
That documentation also mentioned updating the uriworkermap.properties file. Here is an excerpt from that page:
rest in the URL specifies that the request is for a REST service. ColdFusion has a servlet mapping for the same and would direct the request to the servlet that handles REST service. If there is a directory in the server webroot with the same name, you must update the servlet mapping in web.xml file inside wwwroot\WEB-INF directory. Also, you must update the same mapping in the uriworkermap.properties file located under the config\wsconfig\1 of the server directory.
You will need to restart the ColdFusion service after making any changes to these files.
While this will not disable the functionality in ColdFusion it will allow your services to respond under the /rest/ URI because ColdFusion will be listening under a different one that you define.

Related

SOAP/HTTP using different folder mappings in ColdFusion

I'm experiencing some strange behaviour with a ColdFusion 11 server, which (among other things) publishes some web services accessed via both SOAP and HTTP. The server itself is Windows 2012, running IIS. Actual folder config is as follows:
IIS has two websites configured, 'BOB' and 'BOB_Services'. Both have been configured with the CF Server Config tool so that CF handles .cfc, .cfm files. They share a common CFIDE config.
BOB's root is I:/inetpub/BOB
BOB_Services's root is I:/inetpub/BOB_Services
There is a folder mapping configured in CF Admin from '/' to 'I:/inetpub/BOB'. Don't ask me why, no one seems to know.
Normally there is a services.cfc file in BOB_Services ONLY. Yesterday we accidentally copied that same file into the BOB root folder, and all of our SOAP services using BOB_Services\services.cfc started throwing errors. Yet I can query the same webservice via HTTP (eg. using http://bob/services.cfc?method=function1&param1=0 ....etc) and get a valid result.
This is a reference answer in case anyone else comes across this strange behaviour.
It appears that when BOB_Services/services.cfc is called using HTTP GET, the folder mapping
'/' -> 'I:/inetpub/BOB'
is ignored and the actual file used to process the request is I:/inetpub/BOB_Services/services.cfc.
When a function in BOB_Services/services.cfc is called using a SOAP client, the folder mapping is invoked and the file used to process the request is I:/inetpub/BOB/services.cfc, IF IT EXISTS. If it does not exist, the file I:/inetpub/BOB_Services/services.cfc is used as expected.
This behaviour appears to be entirely repeatable - I can make a SOAP request, get one result, change the mapping, make another request and get the other result.

Bluemix SAML and timeout session issue

I've created Web Application running on Java Liberty Runtime on Bluemix. Login is done by using SSO service with SAML enterprise provider. After login user redirected to my app and on every JAX-RS request I get user's credentials by following code:
Subject s = WSSubject.getCallerSubject();
Object credential = s.getPrivateCredentials().iterator().next();
String loginToken = credential.toString();
Everything works fine, but if the user has been idle for more then 10 minutes and then perform any ajax request WSSubject.getCallerSubject() returns null, and I required to refresh application.
I've tried to increase timeout by adding following attribute to web.xml:
<session-config>
<session-timeout>60</session-timeout>
</session-config>
But it didn't help. So I'm looking how can I increase timeout or possible I can retrieve user credentials in a different way?
You need to add the optional element <authCache> to the server.xml file to change the default values for the authentication cache.
As you mentioned in your question, the default value is 10 minutes. To change it to 60 minutes you need to include the following in the server.xml file:
<authCache initialSize="50" maxSize="25000" timeout="60m"/>
The documentation here provides more details and also explains initialSize and maxSize options, I left the default value for these two above and just updated timeout.
If you are deploying your application using the default method of pushing the war file, you will need to use a different approach to deploy the application with a custom server.xml file. Please check the documentation here for options on pushing Liberty profile applications (more specific check sections Server Directory and Packaged Server).
In this case, you may also want to check the server.xml file that is currently deployed and modify that version to add the <authCache> element.
You can get a copy of the file by running the following command:
$ cf files <your_app_name> app/wlp/usr/servers/defaultServer/server.xml

XDS.b testing with SoapUI

I have to implement a simple client to a XDS.b server (SubmitObjectRequest and RetrieveDocumentSetRequest operations), but I'm struggling to get even a simple example of use to work.
I've tried using Mirth Connect's Channel for XDS.b also, but with no use. I even tried to copy its SOAP envelope to use with SoapUI. Didn't work.
I'm using HIEOS deployed on Glassfish as my XDS.b server.
I'm lost and confused. Could anyone give me a guidance on how to make this work?
If the HIEOS is deployed correctly within the Glassfish the service endpoint provides a wsdl definition where the interface is specified. Check the Glassfish for the wsdl of the service.
http://localhost:8080/my-ws/simple?WSDL
Quelle: docs.oracle.com/cd/E18930_01/html/821-2418/gbiyw.html
The list of provided endpoints you can see here:
https://kenai.com/projects/hieos/pages/WebServices
So to retrieve the wsdl you should use for example:
http://localhost:8080/axis2/services/xdsrepositoryb?wsdl
which applies for the ProvideAndRegisterDocumentSet-b transaction of the XDS Repository actor.
You can use the WSDL definition to create a WS request using SOAP UI at first.
SOAP UI creates a request based upon the wsdl definition which can be used to
test a against your XDS repo.
When you know how a SOAP request must be constructed you can try it using Mirth or
create your own client using Apache CXF http://cxf.apache.org/ for example.
Or you use AXIS2 to create a client from the WSDL. Of course does Visual Studio and C# also offer mechanisms to create a WS client directly from a WSDL definition.

Calling GWT RPC service

I have been going through the google tutorial ( which I find very good ) at
https://developers.google.com/web-toolkit/doc/latest/tutorial/RPC
I have the service up and running on my local server and my JavaScript client can call it fine. OK so far. Now, what I want to do is deploy the service on a remote server JoeSoapHost:8080
How do I now tell my client where to send it's requests? I can't see any server/url being created in my RPC call. It just works by magic but now I want to get under the bonnet and start breaking it.
[Edit}
This is the Interface my client uses to know what service on the Server is to be called. I know that my Web.xml web descriptor must have a url that matches this. It has this because my server is invoked ok. Problem is, if I now decide to deploy my server elsewhere how do I tell my client what server/domain name to use?
#RemoteServiceRelativePath("stockPrices")
public interface StockPriceService extends RemoteService
{
StockPrice[] getPrices(String[] symbols);
}
What I want to achieve first is have a simple GWT client calling into an RPC service. I have this working but only when the server is localhost.
Next step, I deploy my app to the Google App Engine. What must I change now because my RPC service in my JavaScript is not being called when I deploy my app to
http://stockwatcherjf.appspot.com/StockWatcher.html
1) Brian Slesinsky excellent document on RPC - https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit#heading=h.amx1ddpv5q4m
2) #RemoteServiceRelativePath("stockPrices") allows GWT code to determine relative to your host/server/domain i.e http//mydomain.com/gwtapp/stockPrices
3) You can search GOOGle IO Sessions from 2009 - 2012 for some more in depth stuff on GWT RPC usage.
#RemoteServiceRelativePath gives the path of the servlet relative to the GWT.getModuleBaseURL() (which is more or less the URL of the *.nocache.js script); it doesn't "just work by magic".
If you deploy your services on a different server than the one serving your client code, then you'll likely hit the Same Origin Policy. CORS can help here, but you'll lose compatibility with IE (up to IE9 included). You'd better stick serving everything from the same origin.

Protecting click once web deployed installations

I have a link on my website to the standard publish page generated by Visual Studio. My concern is that if anybody finds out the URL to that page, they can download my software. Sure, I could password protect the page with the link, but it still would not be protecting the download URL. Are there any ways to secure the click once upload? I have looked around, and it seems like I am stuck in this sense.
Public URL is a security issue in ClickOnce Deployment. However, there is a solution for your problem if your web server has windows and .NET installed. Tell me if you have one ? I will have to come up with another workaround for Linux web server in case you have that.
Brief
Firstly, a bit of information about ClickOnce deployment. When you deploy the application, the GET requests on the server made are (assuming WebDir is the publish directory on the server)
G-1. GET /WebDir/setup.exe (Initial download)
G-2. GET /WebDir/MyApp.Application (setup.exe -url request)
G-3. GET /WebDir/MyApp.Application (.application deployment provider URL request)
G-4. GET /WebDir/Application Files/MyApp_1_0_0_0/MyApp.exe.manifest (Application manifest request)
G-5. GET /WebDir/Application Files/MyApp_1_0_0_0/MyApp.exe.deployand other .deploy files ... (Application file requests)
Implementation
Now, the solution is to intercept these file requests on the server. On IIS, you can attach a custom HTTPHandler and handle the request. On Apache, you can redirect requests to a PHP code using .htaccess files. Apart from this, you will have to generate unique identifier uid for client instances downloaded from the server (can be your license key) and put that in the deployment provider URL query parameters.
Directory Structure
Create an "Application" folder inside your WebDir and restrict access to /WebDir/Application/. Rest everything can be there inside /WebDir/
File Requests
So here's what you do on a Apache web server hosted on a windows machine:
Create a custom download page or use the one created from publishing the application using Visual Studio (but you will have to edit it manually!). Let's assume that page is /WebDir/Download.php
After authenticating user from Download.php, you have to send setup.exe from your code (can do it with readfile() in PHP) to the user. However, the catch is bootstrapper (setup.exe) after installing will do a GET request [G-2]. Don't forget now, that you have to validate this file request. So basically you change the "setup.exe -url" property to include uid before returning the file. For eg: change it to /WebDir/uid/MyApp.Application [G-2]. You can use MsiStuff.exe to change the URL property for the bootstrapper.
Using a .htaccess file, rewrite [G-2] to /WebDir/Handler.php?user=uid. From Handler.php, you can check if it is a valid uid. If it is valid, you will have to include the uid in the deployment provider URL and "Dependent Assemblies Path" in deployment manifest so that if an upgrade request comes (It essentially requests the deployment manifest), you can validate the user there too. Add uid to query string parameters. For eg: change it to /WebDir/MyApp.application?user=uid [G-3]. Don't forget that you will have to resign the manifests once you modify them. Use Mage or write your own code to do that.
So finally, the GET requests on the server will be (assuming uid=1f3rd)
G-1. GET /WebDir/Download.phpAction: return setup.exe with the -url changed
G-2. GET /WebDir/Application/setup.exe/1f3rd/MyApp.ApplicationAction: redirect, validate user, change URL, re-sign and return file
G-3. GET /WebDir/Application/setup.exe/MyApp.Application?user=1f3rdAction: redirect, validate user and return file
G-4. GET /WebDir/Application/1f3rd/Application Files/MyApp_1_0_0_0/MyApp.exe.manifestAction: redirect, validate user and return file
G-5. GET /WebDir/Application/1f3rd/Application Files/MyApp_1_0_0_0/MyApp.exe.deployand other .deploy files ...Action: redirect, validate user and return file
Pros
Application is successfully deployed and upgraded only if all the requests have a valid uid in the URL present.
You can now identify different instances of application on client systems. You can track the update history, do a selective version upgrade/downgrade and much more !
Cons
You will need a windows server to implement the above since you need mage.exe | your-own-.NET-code-signing-application and Msistuff.exe.
You may have minor performance issues since you are performing validation on every file request. You can choose to skip validation on .manifest and .deploy file requests.
You will have to ensure proper security for companies certificate which will be present on the web server for signing (You can store it on the server local file-system if you have the full server to yourself. In that case, it is fine unless somebody breaks into machine itself !)
If you want me to make something clear or explain in detail, feel free to ask. In case you have suggestions for modification to the above, post that too.
I will write a detailed CodeProject article if I have spare time someday.