i have an application which is using this a lot
<cfset SetVariable("b.vari.#c.i#",variables[c.i])>
how can simply it in better way using cf2021 now.
i tried following the urls from a website but i am not sure, they are using some [ operator which i can't get around
i tried like this
<cfset b.vari['c.i'] = variables[ci.i]>
is that above right, i am not sure about and i think the code i have written below foes not make sense, please guide if i am doing anything wrong here
I don't think the code you're talking about could cause a Java heap space issue unless you have low memory allocation settings for the server's JVM config and an extremely high volume of requests. Are you running a single instance of the server? Multiple instances behind a load balancer?
So this code
<cfset SetVariable("b.vari.#c.i#",variables[c.i])>
is the same as
<cfset b.vari[c.i] = variables[c.i]>
is technically
<cfset variables.b.vari[c.i] = variables[c.i]>
So you're double-stacking the same data into the variables scope of the request. Dump the variables scope after that line and you'll see the same data in there twice.
<cfdump var="#variables#">
BUT, a struct and other complex objects in CF are passed by reference and not by value. So both variables should be referencing the same memory space that was taken by variables[c.i].
You might check the -Xms (initial memory allocation) and -Xmx (maximum memory allocation) settings of your CF server's jvm.confg file. You can either edit this in the JVM settings section of CF admin directly in the file of that name.
If you've never edited those values from the defaults, you might have too little memory allocated for your CF server compared to what's available to the server as a whole. It's often the case that your application's usage eventually crosses a threshold that requires you to add and allocate more RAM to the server to handle the increased load.
While you're in there, check if the server is referencing the version of Java that shipped with your CF installation. You might also be behind on the recommended current secure version of Java for your version of CF.
What are the -Xms and -Xmx parameters when starting JVM?
https://www.cfguide.io/coldfusion-administrator/server-settings-java-jvm/
Related
I am trying to use Coldfusion CFPRINT to print UPS labels to a network printer. The starting labels (png files) are great and I can print them locally to the zebra printer and they print and work wonderfully. The barcodes produced by CFPRINT however are of such poor quality that a barcode scanner cannot read them. My research shows that Coldfusion uses the jpedal java library which resizes the images to 72 dpi - which is just not crisp enough for a scanner.
I read about using a jpedal setting: org.jpedal.upscale=2 but I have no clue as to where you would utilize this.
Any suggestions on how to fix this CFPRINT resolution issue using Coldfusion?
(Just to add a bit more detail to the comments)
That is a JVM argument. There are several ways to apply it:
Add the setting to your jvm.config file manually. Backup the file first. Then add -Dorg.jpedal.upscale=2 to the end of the java.args section. Save the changes and restart the CF Server. Do not skip the backup step! Errors in the jvm.config file can prevent the server from starting. So it is important to have a good copy you can restore if needed.
Open the CF Administrator and select Server Settings > Java and JVM > JVM Arguments. Add -Dorg.jpedal.upscale=2 to the end of the arguments. Save the settings and restart the CF server.
Again, I would strongly recommend making a backup of the jvm.config file first. As #Mark noted in the comments, some versions of CF have been known to mangle the jvm.config file, which could prevent the server from starting. But as long as you have a good backup, simply restore it and you are good to go.
IIRC, you could also set the property at runtime, via code. However, timing will be more of a factor. Their API states system properties must be set before accessing JPedal. The docs are not clear on exactly what that means. However, the implication is the system property is only read once, so if you set it too late, it will have no affect.
// untested
sys = createObject("java", "java.lang.System");
prop = sys.getProperties();
prop.setProperty("org.jpedal.upscale", "2");
sys.setProperties(prop);
Side note, I was not familiar with that setting, but a quick search turned up the CF8 Update 1 Release Notes which mention this setting "improves sharpness, but it also doubles the image size" and also increases memory. Just something to keep in mind.
We have a collection of VB.NET / IIS web services on some of our servers, and they have web.config files in the websites' root directories that they're already reading configurations from. There is a new configuration that needed to be added that will immediately be quite a bit longer than the others, and it'll only stand to grow. It's essentially a comma-separated value, and I'm wanting to keep it specifically in a configuration file of some sort.
At first I started doing this with a text file, but there was a problem with that. The text file's contents could change while web service threads and processes are running, so they would need to essentially re-read the file every time they needed to access its values. I thought about using some sort of caching, but unless the web services are completely restarted each time the file is updated, caching would block updates to the file from being used immediately. But reading from a text file each time is slow...
Then came the idea of putting that value in web.config, along with the other configurations the services are already using. When web.config is altered, the changes are able to be cached in the code, on top of coming into play immediately. However web.config is, well, web.config, and it's not a totally trivialized text file that is simply read out of in the code. IIS treats web.config in a special manner.
I'm tempted to think any negative consequences of putting a comma-separated value in web.config would be outweighed, in comparison to storing them in a text file (or a database, which probably can't be used for this anyway), but I guess I better ask.
What are the implications of storing a possibly lengthy, comma-separated value in web.config, instead of in its own little text file? Is either file a particularly good or bad idea? To me, it seems like web.config would be easy to get along with without having to re-read the file over and over, but there's certainly more to it than the common user is aware. Thanks!
I recommend using the Application Cache for this:
http://msdn.microsoft.com/en-us/library/vstudio/6hbbsfk6(v=vs.100).aspx
So my C++ CGI program generates some html-page with several links. How can I make within the same C++ process that after clicking this links will be displayed some others pages with content depending on what hyperlink was clicked?
For now I just have variant that there will be other C++ CGI program that will read URL param with getenv, and this param will be different for every link from my first page. But I believe there must be a way of doing this with one C++ process.
You are trying to store session information in the memory of your CGI program. CGI protocol doesn't allow this by itself. You must store session information somewhere else. Your options are:
Output HTML where result of your calculations is embedded in URLs, so that next execution will see those results (if that information is sensitive, this is a security flaw - you may overcome this with safe encryption).
Store results outside your C++ program memory (a file?). Then output a cookie or embed a session identifier in the URLs. In the next execution, you perform a lookup with session identifier then load those results from your server. You must take care to free old data to avoid space exhaustion.
Turn your C++ application into a web server! Your C++ application will answer HTTP requests (it will not be only a CGI application). That may be overkill, but might be necessary. I think there are free open source libraries that helps on that, or you can develop an Apache (httpd) module.
Hope that answers your question!
Some programs like ProcessExplorer are able to read strings in memory (for example, my error message written in the code could be displayed easily, even though it is compiled already).
Imagine if I have a password string "123456" allocated sequentially in memory. What if hackers are able to get hold of the password typed by the user? Is there anyway to prevent strings from being seen so clearly?
Oh yes, also, if I hash the password and sent it from client to server to compare the stored database hash value, won't the hacker be able to store the same hash and replay it to gain access to the user account? Is there anyway to prevent replaying?
Thank You!
I believe you are confusing two things. The strings ProcessExplorer is finding are also able to be found by the "strings" command in Unix. It just dumps all the stored strings in an executable not the current memory.
Unless you compiled a User password into your program, the memory allocated to store the data shouldn't be read by ProcessExplorer.
There are numerous issues that can occur. Your best bet is to ensure that no other code can run within your process space. Since the days of virtual memory, each process gets its own virtual memory space, ideally preventing any other program from accessing and messing with the memory of other programs. There are ways to detect if your program is being debugged.
You also need to ensure that the memory you are using to store the password is never written to disk or paged out. This web site can point you in the right direction. https://www.securecoding.cert.org/confluence/display/seccode/MEM06-C.+Ensure+that+sensitive+data+is+not+written+out+to+disk
[edit]
I wanted to expand upon my previous post by talking about replay prevention.
If you are truly serious about a complete solution you will need to implement two-way authentication using a PKI system. Your client will have a certificate and so will your server. The client's private key will only be able to unlocked with a password the user will enter. This will allow the server to verify the the client is who he says he is. The client will then verify the server is who he says he is the same way as the client.
By using this system you prevent someone from possing as a server and attempting to get you to send it your password.
This is a topic I can't cover too well on this web site. You will need to research Certificate Authorities and PKI.
Your vulnerabilities are then:
1. Peaking into current memory to extract the password
2. Social engineering
Reference: http://en.wikipedia.org/wiki/Public_key_infrastructure
Andrew's answer gives you good hints for protection of in-memory strings. Regarding replaying - you're certainly right that if someone else intercepts the hashed password, they can replay it and compromise security. The way to defeat that is challenge-response authentication: http://en.wikipedia.org/wiki/Challenge-response_authentication
Do not store plain passwords in the memory (you can XOR them at least). And read Introduction Into Windows Anti-Debugging
I don't know how is it usually done, but if it's critical for you, you may extend whatever string class you use to store your string at least primitively encrypted and to overwrite it with zeroes or with random data upon destruction/reassignment.
I'm supporting a legacy application on ColdFusion 7, and the pages are full of painful amounts of whitespace that I'd like to gzip away.
I know I can:
manually compress everything in an index type file (reference)
enable it in the web.xml (which I don't have access to)
But can I just throw the right < cfheader > or something akin to a .htaccess that triggers gzipping on this directory?
There are two ways to implement compression. At the web server level (apache 1.3 with mod_gzip or mod_deflate, IIS_6, IIS_7) or the application server level (coldfusion via a servlet filter).
I'm afraid those are the only options available to you for compression.
Otherwise you'll be looking at one or more of these:
enabling whitespace suppression via
cf administrator.
using <cfsetting
enablecfoutputonly="true"/> where
possible.
wrapping code with
<cfprocessingdirective
suppressWhiteSpace="yes"></cfprocessingdirective>
wrapping code with <cfsilent></cfsilent>
The only time I've seen CF handle GZIP itself, IIRC, is when using the internal (not for production) web server. I've always seen compression handled at the webserver (IIS or Apache) level.
If there is specific code that is dumping large amounts of whitespace, there are a number of options for dealing with it. Several are roughed out in an article by Ray Camden.
Personally, I don't worry about whitespace much unless it's really bad. I turn off output in CFCs (if something should be displayed, I return it), and I use CFSilent blocks around code blocks that shouldn't display output anyway.