We have a dedicated server running CentOS and Coldfusion 8.
All cfmail email is routed through Google with cfmail and smtp.
Every now and then, when cfmail is used, the 'FROM' field uses an address from a totally different website.
For instance:
Use form on Site A
Get an email: "Subject: On Site A From: siteb#siteb.com"
Where the from is a completely different variable in another set of code on another part of the server- there is no reason it should see this.
On the other side, sometimes sending an email to sitea#sitea.com has email wind up in Site B inbox, a completely different Google account.
What causes this to happen? Some kind of memory/cache issue? Or is there a funky DNS record causing issue?
Example:
Application.cfm (starts with some UDF includes, and then):
<cfinvoke component="#request.componentPath#.variables" method="getGlobal" />
Variables.cfc (a lot of variables defined within, but here is the cfmail vars):
<cffunction name="getGlobal" access="public" output="false" returntype="void">
<cfscript>
request.siteEmail = "email#mysite.com";
request.siteMailServer = "smtp.gmail.com";
request.siteMailUsername = "root#mysite.com";
request.siteMailPassword = "[redacted]";
</cfscript>
</cffunction>
It sounds like it's possible it could be a var scoping issue, but we can't know for sure until you share some code...
Looks like you're running multiple sites? there's a setting in the CF caching page in admin to do with caching web server paths:
From http://help.adobe.com/en_US/ColdFusion/9.0/Admin/WSc3ff6d0ea77859461172e0811cbf3638e6-7ffc.html :
Disabling the cacheRealPath attribute To ensure that ColdFusion always returns pages from the correct server, disable Cache Web Server Paths in the Caching page of the ColdFusion Administrator. (When you use the multiserver configuration, set the cacheRealPath attribute to false for the ProxyService in the jrun_root/servers/servername/SERVER-INF/jrun.xml file.)
Might not be it, but it's at least quick to try out.
Related
I am migrating websites from a server using CF 8 to a new one using CF 10. In this one site, I have a query that looks up talent and then writes the resulting list to a cfcookie. On my computer with any browser it works correctly. My client uses the same browser as I normally use (Safari) and his browser is not updating the cfcookie with the new talent list after a search. They are very unhappy making me unhappy also. Any ideas as to what might be causing this problem.
In the application.cfm (yes, I know I should be updating to cfc but not enough hours in the day):
<CFAPPLICATION NAME="lil"
CLIENTMANAGEMENT="yes"
SESSIONMANAGEMENT="yes"
SESSIONTIMEOUT=" #createTimeSpan(0,0,30,0)#"
APPLICATIONTIMEOUT=" #createTimeSpan(0,1,0,0)#"
clientstorage="cookie">
Setting the cfcookie:
<cfif isdefined('getTalent.recordcount') and getTalent.recordcount gt 0>
<cfcookie name="tSearch" value="#valueList(getTalent.talentID)#" httponly="true" expires="1">
</cfif>
How large is the amount of data you are storing in the cookie, and could the client be storing more than you are? Are they possibly using a cookie-blocking security app of some kind?
In a bigger-picture kind of mindset, if the user is doing a search and getting results, rather than storing the results in a cookie, why not use either a session-scoped variable, or simply use the CF identity cookies already in place to store their results in a temporary database location? Cookie issues can be harder to track down, but unless you're not managing sessions in your Application.cfc or cfapplication tag, each user is already getting a unique ID which you can leverage server-side for this type of thing.
One last thought... are you doing any sort of CFLOCATION redirect, after attempting to store the cookie? Redirecting can cause CFCOOKIE commands to not be honored, because in essence the user's browser is redirected before it receives the response.
How can I get the URL using ColdFusion?
I tried the following but it did not return the Named Anchor.
For example http://www.makeup.edu/test/#abc
<cfdump var=#cgi#>
You can't, 'cause although it is in the URL, it is only meant for the client. It will not be sent to the server, therefore you can never find that in the CGI scope.
As Henry says, you can't get them with ColdFusion because they are never sent with the request. What you need to do is to pull them out with Javascript (which can access them), and then send them back to the server via some other mechanism, like putting them in a cookie or something. It depends on the situation as to how you tackle that part, but it's probably a different question anyhow.
Bottom line: the info is never transmitted with the request, so the web server doesn't get it, so the web server cannot pass it to ColdFusion, so ColdFusion does not receive it.
Add an additional url parameter to identify the anchor. So you could create the link http://www.makeup.edu/test/?anchor=1#abc
The user clicks on the link and the anchor goes to the right place and then you could use:
<cfif ISDEFINED("url.anchor")>
<cfif url.anchor EQ 1>
... do stuff here...
</cfif>
</cfif>
I am testing consuming a web-service and I'm getting an error.
Here is the web-service component:
<cfcomponent >
<cffunction name="listBooks" access="remote" returntype="string" output="no" >
<cfquery name="getBooks" datasource="cfbookclub" >
SELECT bookID, title, bookDescription, genre
FROM books
ORDER BY title desc
</cfquery>
<cfsavecontent variable="bookList" >
<books>
<cfoutput query="getBooks" >
<book id="#getBooks.bookID#" >
<title>#XMLFormat( getBooks.title )#</title>
<description>#XMLFormat( getBooks.bookDescription )#</description>
<genre>#XMLFormat( getBooks.genre )#</genre>
</book>
</cfoutput>
</books>
</cfsavecontent>
<cfreturn bookList >
</cffunction>
Here is the consuming page:
<cfinvoke
webservice="http://127.0.0.1/books.cfc?wsdl"
method="listBooks"
returnvariable="rawXMLBookList" >
</cfinvoke>
Seems simple enough - I was actually trying to pass an argument "genre" when I got the initial error,
Web service parameter name category cannot be found in the provided parameters {genre}.
So I removed all reference to arguments, and STILL get this error
Web service operation with parameters {} cannot be found.
The error makes it sound like the web-service cannot be found, however if I cut and paste the url into my browser I get the expected XML doc...
There was another post like this on this site, but the problem was a base64 issue, I'm just returning txt so I don't think it's a similar problem, even through the error msg is similar.
Try adding the refreshWSDL argument to your <cfinvoke> call and see if that helps.
<cfinvoke
webservice="http://127.0.0.1/books.cfc?wsdl"
method="listBooks"
refreshwsdl="yes"
returnvariable="rawXMLBookList">
</cfinvoke>
Setting refreshwsdl="yes" reloads the WSDL file and regenerates the artifacts used to consume the web service.
Note you do not want to keep this setting for all of your requests. You just need to set it for one request to refresh the artifacts. Then you should change it back to refreshwsdl="no". Until you need it again.
Here is an excerpt from Charlie Arehart's Blog about the refreshWSDL argument:
Why should you have to refresh the web service metadata?
Just to back up for a moment, the problem stems from CF's attempt to help. On the first request for a given web service, CF does some caching to make future requests go faster, not caching the results of the web service method but rather the artifacts used by CF based on the description of the web service itself.
CF uses the web service description (WSDL) reported at the time of that first call to create a java proxy/stub based on that, which it then reuses on future calls from CF to that web service.
The issue arises if/when the web service metadata changes. CF won't know, and will continue to use the older cached proxy/stub, and your long-running code may fail if it doesn't match the new WSDL returned by the web service.
So we need a way to tell CF to refresh its cache of that proxy stub.
This new feature is certainly the easiest way to make that happen, but it's not the only way.
We are making a cfhttp call to connect to an https web service.
We are getting the this error:
Connection Failure: Status code unavailable
I searched Google but have found no solutions.
From the production server I am able to hit the web service URL.
I am a .Net developer and I am not sure of this technology.
Any pointers will be helpful.
Here is the line of code we are using to make the connection:
<cfhttp url="#arguments.TheIP#" method="post" throwonerror="true" timeout="45">
<cfhttpparam type="header" name="SOAPACTION" value="#arguments.TheHeader#">
<cfhttpparam type="XML" value="#arguments.TheXML#">
</cfhttp>
I have faced / solved this a few times, the snippet below hopefully will work for you. I highly recommend learning about it in stead of simply trying it.
I place this in my Application.cfc, but you could put it right in your script right before the cfhttp call as well.
<!--- fix for HTTPS connection failures --->
<cfif NOT isDefined("Application.sslfix")>
<cfset objSecurity = createObject("java", "java.security.Security") />
<cfset objSecurity.removeProvider("JsafeJCE") />
<cfset Application.sslfix = true />
</cfif>enter code here
Hum... First thing that appears odd is your IP argument as mentioned by barnyr. The response you are getting makes me think you are getting NO response at all (the request is completely ignored, not just erring). So some setting is causing them to ignore your request.
As of CF9 I use cfscript to do this kind of thing via HTTP when I can't use regular webservice java object proxy stubs.
Here is a working SOAP call via http() (because of .net to cf inability to communicate complex object hash maps via regular soap I resorted to this, among other things).
This is a cf to .net service call so it might be relevant for you as they are using just the built in tools to gen their SOAP service which was not perfectly Axis 1 SOAP happy-go-lucky.
In particular I had to play with some of the extra settings and headers to get it just so and specifically add the soap action into a header (which is usually derived from the SOAP body envelope).
Additionally, I am using oasis security which I had to stuff inside the envelope/body.
Here is the code (inside a cfc) that you might try updated as you need:
//////////////////////////////////////////////////////////////////////////
// BUILD HTTP REQUEST
//////////////////////////////////////////////////////////////////////////
Local['SoapAction'] = "XYZ.Commercial.Mapping.ServiceContracts/IService/#Arguments.szMethodName#"; // THIS IS CASE SENSITIVE
var oH = new Http();
oH.setMethod('post');
oH.setCharset('utf-8');
oH.setUserAgent('Axis/1.2.1');
oH.setTimeout(30);
oH.setURL(Arguments.szURL);
// INCLUDING THE SOAPACTION AS A HEADER IS SPECIFIC TO XYZ - USUALLY THE OPERATION IS DECIPHERED FROM THE ENVELOPE BODY TAGS - XYS REQUIRES THIS PATHING TO MATCH FOR THE SOAP ACTION HEADER VALUE
oH.addParam(type="HEADER", name="SOAPAction", value='#Local.SoapAction#');
oH.addParam(type="HEADER", name="Content-Type", value='text/xml');
oH.addParam(type="body", value=Arguments.szBody);
///////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////
// EXECUTE HTTP
Local['rsHttpSend']= oH.send();
// SET RESULTS
Local.nStatusCode = val(Local.rsHttpSend.getPrefix().StatusCode);
Local.szResponse = Local.rsHttpSend.getPrefix().FileContent;
Local.szHeader = Local.rsHttpSend.getPrefix().Header;
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
This approach was coupled with using SoapUI to verify the final soap body post was valid. So if you can do that too, you should be able to use this vector.
Let me know if you get any farther.
Here are a list of things to check:
The variable for the URL is TheIP. Make sure this actually a properly
formatted URL, not just a URL.
Check that the target server's certificate is installed in the JVM's
trust store. in Windows and I think .Net, the system's own
certificate store is used, so if your browser can get to the URL
you're ok. In Java there is a file which contains a list of Trusted
Certs. Instructions on importing those certs are in the CF docs for
CFHTTP.
Check the ColdFusion logs for evidence of failure.
c:\coldfusion9\logs\exception.log is probably a good place to start.
Make sure your cfhttp link is correct. I face this issue and it totally based on incorrect cfhttp link.
We've been failing our PCI scans because ColdFusion has predictable CFIDs. The exact FAIL we get is "Predictable Cookie Session IDs". Now the CFTOKEN is no longer predictable since I've configured CF to use UUID for CFTOKEN, however, the CFID is still predictable and unaffected by any changes in CF Admin.
I don't really know why the CFID being predictable is a threat, but they want us to fix it.
I have been unable to find anything on the matter by googeling, and I'm really not sure what else to do.
Has anyone else dealt with something like this? Any suggestions?
EDIT:Here is what my Application.cfc file looks like:
<cfcomponent output="false">
<cfset this.name="DatabaseOnline">
<cfset this.sessionManagement=true>
<cfset this.setDomainCookies=true>
<cfset this.setClientCookies=true>
<cfset this.sessionTimeOut=#CreateTimeSpan(0,20,0,0)#>
</cfcomponent>
And my CF admin looks like this: http://i.imgur.com/k9OZH.png
So how do I disable CFID?
Using J2EE session variables should address that problem.
To do that go to CF Administrator. Server Settings --> Memory Variables and check the 'Use J2EE session variables' check box.
You can find some more information here http://helpx.adobe.com/coldfusion/kb/predictable-cookie-session-ids-reported.html
Explain to the scanning agent that the CFID is sequential, but is not valid without a corresponding CFTOKEN cookie which is randomized. Since the session cannot be hijacked with the ID alone, it mitigates the reason for the scan failure. Their automated test assumes that the CFID cookie controls the session on its own, which is not the case. Every scanning vendor that I've worked with has accepted this as a mitigating factor and either disabled or overridden that specific test for me on CF-based sites.
Alternately, if none of the sites on the CF server use session variables, you can disable session management entirely and CF won't issue the cookies at all. If they are needed, the above explanation of how CF sessions are managed should get you through.