RE: [ACFUG Discuss] Another CFMAIL Problem
Thanks guys. Now I have a number of other ways to skin this cat if and when she scratches me again - which I'll have to wait for since my client would not pay for me to do that till there's a problem to fix!-Original Message- From: Charlie Arehart <[EMAIL PROTECTED]> Sent: Nov 11, 2008 10:10 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] Another CFMAIL Problem <zzz!--[if gte="" mso="" 9]=""> <zzz![endif]--><zzz!--[if gte="" mso="" 9]=""> <zzz![endif]--> Just to clarify, in case it may matter to anyone, that ability to delete attachments after mail is sent is new in 8.01, specifically. /charlie From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Knudsen Sent: Monday, November 10, 2008 9:51 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem There are certainly many ways to skin this cat. I would not trust your original approach from bad experiences in the past. THings may have changed. Hey, things have changed! CFMail in CF8 has ability to delete attachments after being sent??? - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - -To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ http://www.mail-archive.com/discussion%40acfug.org/List hosted by http://www.fusionlink.com-
RE: [ACFUG Discuss] Another CFMAIL Problem
Just to clarify, in case it may matter to anyone, that ability to delete attachments after mail is sent is new in 8.01, specifically. /charlie From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Knudsen Sent: Monday, November 10, 2008 9:51 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem There are certainly many ways to skin this cat. I would not trust your original approach from bad experiences in the past. THings may have changed. Hey, things have changed! CFMail in CF8 has ability to delete attachments after being sent??? - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Another CFMAIL Problem
Hi,
As per your quote,
then wouldn't it be possible that cfmail could grab the old value from the
SQL Server column (presumably via its 'query=' parameter?) before my SQL
Server update statement stuffs the new value into it?
Well, once you store something, lets say beforeupdate_identColumn.pdf , now
you have a file mapping to identity column. So lets say user changes or
modifies something, then you do update *first* based of identity column.
Then you either create that pdf or send it as an attachment. Makes sense? My
feeling is that once you have anything in DB, you are the master of things.
You can do pretty much anything like update, track changes, come back at
later time and still create docs which might be from way back in time and
what not. Bottom line, you are in control.
Here is simple logic :
step 1. create pdf content variable . I guess you could do this,
cfsavecontent variable=pdfcontenttableblah blah
/table/cfsavecontent
step 2. insert into db. insert into pdf_table(pdf_content) values
('#pdfcontent#') ( what i mean here is to save pdf text with table
formattting etc in the column.
step 3. Now whenever your ready you could
a. lets say user updates pdfcontent, then you do udpate query first, so you
have latest content.
step 4. get the latest content from the table and
a. create pdf using cfdocument #pdfcontent#/cfdocument or
b. send it as an attachment.
this way you will know for sure, if it was right content or not. Right now
seems to me, its more of guess work and there is no way to make sure you are
sending the so called cache vs updated content.
hope that helps.
Ajas Mohammed.
On Mon, Nov 10, 2008 at 12:23 AM, Dawn Hoagland [EMAIL PROTECTED]wrote:
IF you can send a link to the server AND he always needs the latest version
(and assuming it doesn't take long to generate the PDF) - I would send a
link to a page that generates it on the fly every time and allow him to
download that version when needed - as previously mentioned by Howard. This
eliminates any issues to do with email latency (or the possibility of
caching) and gives the opportunity to close some security holes created by
leaving content in an unsecured location.
Dawn
On Sun, Nov 9, 2008 at 8:26 PM, Peyton Todd [EMAIL PROTECTED]wrote:
Doug, your guess that the email gets sent before the new PDF gets built
rings true to me. It would explain the problem on my client's server, as
well as the fact that it's not happening to me right now testing the system
working on my own PC as localhost. It jogs my memory that my coworker
experienced a similar problem back about 2001, when I was programming
ColdFusion in New York City. (?New York City!?? Get a rope!)
Dean, doesn't it make sense to you that the e-mail could get sent before
the second version of the file gets built, so it merely picks up what it
finds on the disk , namely, the earlier version of the file? Actually, come
to think of it, that would not be an instance of caching.
Ajas, I don't know, but it seems to me that saving the PDF into a SQL
Server column might have the same problem as that described by Doug: if
these operations can be performed asynchronously, then wouldn't it be
possible that cfmail could grab the old value from the SQL Server column
(presumably via its 'query=' parameter?) before my SQL Server update
statement stuffs the new value into it?
Howard, No, I didn't mean the office manager might get mixed up on which
file is which - he's reasonably computer literate, and knows perfectly well
that the one on top was sent later (Whoops! It just occurred to me that that
might not always be true if there's a glitch in the e-mail process...).
Anyway, though, what I did mean is that it's simply the older version of the
file that gets attached to the e-mail. Your idea of sending a link seems
like a good one, and I may try that but ...
Naming the PDF by the Job Number instead of by the reporter's ID is
necessary of regardless of whether I attach the file or send a link. In
either case, I'd be writing the file to disk. If I were to delete any old
copy beforehand, what are the chances that (if this asynchrous story is
true) cfmail would fail to find the file when it looks for it and throw an
error?
Peyton
-Original Message-
From: Howard Fore
Sent: Nov 8, 2008 8:12 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Another CFMAIL Problem
I think what he means is that if a recorder creates a file and sends it,
then corrects it and sends again, the recipient could open the first one and
think it is the most current version when it isn't. It wasn't identified as
an issue by Peyton but I could see how it could cause someone an issue. My
response to that would be to not mail the PDF as an attachment but rather
email a link to the user. The link would either lead to a real PDF, stored
on disk, or to a CFM file that generates the PDF when it is requested. That
would get rid of any caching
Re: [ACFUG Discuss] Another CFMAIL Problem
I was at my client's site today, and adopted the easiest solution, which was: (a) writing the PDFs to a directory outside the web root and reading them from there; (b) naming the PDFs with the job number instead of the reporter's initials; and (c) deleting any existing PDF by that name before the process begins (except in one rare, non-mission-critical situation, where, as a test, I decided to wait and see if it bites me).Ajas, assuming that I delete any PDF by the same name before I begin, your scenario of writing any change PDF content to a database and building the PDF from there only after the updates to the database are performed does solve the problem I posed to you, but I still have a question regarding your step 4, which I repeat below for ease of reference: step 4. get the latest content from the table anda. create pdf using cfdocument #pdfcontent#/cfdocument orb. send it as an attachment.My question: If I create the PDF from the saved data column, and if the root cause is caching (which remains theoretical), couldn't cfemail still simply go with the cached copy in cases where the same job number is being updated? Yes, one would suppose that deleting the file would have led a smart cache-management program to clear its namesake from the cache, but then a smart cache-management program ought to have known better than to go with the cached copy of a PDF which gets re-written directly, without the intermediary of a database, should it not? (Keeping in mind - I say again - that the caching explanation may be false anyway.)Dawn, my page already re-generates the PDF every time on the fly. But maybe I don't understand your comment: since you say it patches the security hole, is it your idea that the PDF never gets written to disk? Howard, if I were to sent the office manager a link to the PDF instead of attaching the PDF to his email, how would I do that? Now that I am writing the PDFs to a directory outside the web root, how could a link reach that directory? And if I continue to place the PDFs in a subdirectory of the web root, how could I secure it? Doug and Dean, have either of you convinced the other that either the caching theory or the asynchronous theory could be correct, or that neither could be? If the problem goes away, then of course it's academic. But since I'm an academic myself...PeytonP.S. Believe me, I'm not making all this up. The problem is a real one. The solution I put in today means this problem would now occur - if it does still occur - only in the rare case when a reporter sends a job report and soon afterwards corrects it and sends it again, as opposed to the frequent case where the reporter reports two different jobs one after the other.-Original Message-
From: Ajas Mohammed <[EMAIL PROTECTED]>
Sent: Nov 10, 2008 9:20 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Another CFMAIL Problem
Hi,As per your quote, then wouldn't it be possible that cfmail could grab the old value from
the SQL Server column (presumably via its 'query=' parameter?) before
my SQL Server update statement stuffs the new value into it?Well, once you store something, lets say beforeupdate_identColumn.pdf , now you have a file mapping to identity column. So lets say user changes or modifies something, then you do update *first* based of identity column. Then you either create that pdf or send it as an attachment. Makes sense? My feeling is that once you have anything in DB, you are the master of things. You can do pretty much anything like update, track changes, come back at later time and still create docs which might be from way back in time and what not. Bottom line, you are in control.
Here is simple logic :step 1. create pdf content variable . I guess you could do this, cfsavecontent variable="pdfcontent"tableblah blah /table/cfsavecontentstep 2. insert into db. insert into pdf_table(pdf_content) values ('#pdfcontent#') ( what i mean here is to save pdf text with table formattting etc in the column.
step 3. Now whenever your ready you could a. lets say user updates pdfcontent, then you do udpate query first, so you have latest content.step 4. get the latest content from the table and a. create pdf using cfdocument #pdfcontent#/cfdocument or
b. send it as an attachment.this way you will know for sure, if it was right content or not. Right now seems to me, its more of guess work and there is no way to make sure you are sending the so called cache vs updated content.
hope that helps.Ajas Mohammed.On Mon, Nov 10, 2008 at 12:23 AM, Dawn Hoagland [EMAIL PROTECTED] wrote:
IF you can send a link to the server AND he always needs the latest version (and assuming it doesn't take long to generate the PDF) - I would send a link to a page that generates it on the fly every time and allow him to download that version when needed - as previously mentioned by Howard. This eliminates any issues to do with email latency (or the possibility of caching) and gives the opportunity to clo
Re: [ACFUG Discuss] Another CFMAIL Problem
There are certainly many ways to skin this cat. I would not trust your
original approach from bad experiences in the past. THings may have
changed. Hey, things have changed! CFMail in CF8 has ability to delete
attachments after being sent???
Here is a fairly recent thread on this topic
http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:54028 There
are some links in there discussing inline attachments either using CFMail or
dropping to Java mail.
inline attachments, no file saving needed at all
http://blog.pengoworks.com/index.cfm/2007/10/26/Using-CFMAIL-to-send-attachments-stored-in-memory
HTH
Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?
On Mon, Nov 10, 2008 at 9:29 PM, Peyton Todd [EMAIL PROTECTED]wrote:
I was at my client's site today, and adopted the easiest solution, which
was: (a) writing the PDFs to a directory outside the web root and reading
them from there; (b) naming the PDFs with the job number instead of the
reporter's initials; and (c) deleting any existing PDF by that name before
the process begins (except in one rare, non-mission-critical situation,
where, as a test, I decided to wait and see if it bites me).
Ajas, assuming that I delete any PDF by the same name before I begin, your
scenario of writing any change PDF content to a database and building the
PDF from there only after the updates to the database are performed does
solve the problem I posed to you, but I still have a question regarding your
step 4, which I repeat below for ease of reference:
step 4. get the latest content from the table and
a. create pdf using cfdocument #pdfcontent#/cfdocument or
b. send it as an attachment.
My question: If I create the PDF from the saved data column, and if the
root cause is caching (which remains theoretical), couldn't cfemail still
simply go with the cached copy in cases where the same job number is being
updated? Yes, one would suppose that deleting the file would have led a
smart cache-management program to clear its namesake from the cache, but
then a smart cache-management program ought to have known better than to go
with the cached copy of a PDF which gets re-written directly, without the
intermediary of a database, should it not? (Keeping in mind - I say again -
that the caching explanation may be false anyway.)
Dawn, my page already re-generates the PDF every time on the fly. But maybe
I don't understand your comment: since you say it patches the security hole,
is it your idea that the PDF never gets written to disk?
Howard, if I were to sent the office manager a link to the PDF instead of
attaching the PDF to his email, how would I do that? Now that I am writing
the PDFs to a directory outside the web root, how could a link reach that
directory? And if I continue to place the PDFs in a subdirectory of the web
root, how could I secure it?
Doug and Dean, have either of you convinced the other that either the
caching theory or the asynchronous theory could be correct, or that neither
could be? If the problem goes away, then of course it's academic. But since
I'm an academic myself...
Peyton
P.S. Believe me, I'm not making all this up. The problem is a real one. The
solution I put in today means this problem would now occur - if it does
still occur - only in the rare case when a reporter sends a job report and
soon afterwards corrects it and sends it again, as opposed to the frequent
case where the reporter reports two different jobs one after the other.
-Original Message-
From: Ajas Mohammed
Sent: Nov 10, 2008 9:20 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Another CFMAIL Problem
Hi,
As per your quote,
then wouldn't it be possible that cfmail could grab the old value from the
SQL Server column (presumably via its 'query=' parameter?) before my SQL
Server update statement stuffs the new value into it?
Well, once you store something, lets say beforeupdate_identColumn.pdf , now
you have a file mapping to identity column. So lets say user changes or
modifies something, then you do update *first* based of identity column.
Then you either create that pdf or send it as an attachment. Makes sense? My
feeling is that once you have anything in DB, you are the master of things.
You can do pretty much anything like update, track changes, come back at
later time and still create docs which might be from way back in time and
what not. Bottom line, you are in control.
Here is simple logic :
step 1. create pdf content variable . I guess you could do this,
cfsavecontent variable=pdfcontenttableblah blah
/table/cfsavecontent
step 2. insert into db. insert into pdf_table(pdf_content) values
('#pdfcontent#') ( what i mean here is to save pdf text with table
formattting etc in the column.
step 3. Now whenever your ready you could
a. lets say user updates pdfcontent, then you do udpate query first, so
you have latest content.
step 4. get
Re: [ACFUG Discuss] Another CFMAIL Problem
On Mon, Nov 10, 2008 at 9:29 PM, Peyton Todd [EMAIL PROTECTED]wrote: Howard, if I were to sent the office manager a link to the PDF instead of attaching the PDF to his email, how would I do that? Now that I am writing the PDFs to a directory outside the web root, how could a link reach that directory? And if I continue to place the PDFs in a subdirectory of the web root, how could I secure it? What I would do is not generate the PDF until requested. That is, email the user a link to a CFM page that compiles the PDF from db and returns it to the user. Alternately if there is a business requirement that the PDF actually exist on disk, put it a place outside the webroot and use the cfcontent tag to serve it up via the link in the email. -- Howard Fore, [EMAIL PROTECTED] The universe tends toward maximum irony. Don't push it. - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Another CFMAIL Problem
Doug, your guess that the email gets sent before the new PDF gets built rings true to me. It would explain the problem on my client's server, as well as the fact that it's not happening to me right now testing the system working on my own PC as localhost. It jogs my memory that my coworker experienced a similar problem back about 2001, when I was programming ColdFusion in New York City. (?New York City!?? Get a rope!)Dean, doesn't it make sense to you that the e-mail could get sent before the second version of the file gets built, so it merely picks up what it finds on the disk , namely, the earlier version of the file? Actually, come to think of it, that would not be an instance of caching. Ajas, I don't know, but it seems to me that saving the PDF into a SQL Server column might have the same problem as that described by Doug: if these operations can be performed asynchronously, then wouldn't it be possible that cfmail could grab the old value from the SQL Server column (presumably via its 'query=' parameter?) before my SQL Server update statement stuffs the new value into it?Howard, No, I didn't mean the office manager might get mixed up on which file is which - he's reasonably computer literate, and knows perfectly well that the one on top was sent later (Whoops! It just occurred to me that that might not always be true if there's a glitch in the e-mail process...). Anyway, though, what I did mean is that it's simply the older version of the file that gets attached to the e-mail. Your idea of sending a link seems like a good one, and I may try that but ... Naming the PDF by the Job Number instead of by the reporter's ID is necessary of regardless of whether I attach the file or send a link. In either case, I'd be writing the file to disk. If I were to delete any old copy beforehand, what are the chances that (if this asynchrous story is true) cfmail would fail to find the file when it looks for it and throw an error?Peyton-Original Message- From: Howard Fore <[EMAIL PROTECTED]> Sent: Nov 8, 2008 8:12 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem I think what he means is that if a recorder creates a file and sends it, then corrects it and sends again, the recipient could open the first one and think it is the most current version when it isn't. It wasn't identified as an issue by Peyton but I could see how it could cause someone an issue. My response to that would be to not mail the PDF as an attachment but rather email a link to the user. The link would either lead to a real PDF, stored on disk, or to a CFM file that generates the PDF when it is requested. That would get rid of any caching issue as the file requested is always the latest version. On Sat, Nov 8, 2008 at 6:19 PM, Dean H. Saxe [EMAIL PROTECTED] wrote: What "things" get asynchronous? If what you say is true, email would regularly go out without complete attachments. I think you're way off on this one. -- Howard Fore, [EMAIL PROTECTED]"The universe tends toward maximum irony. Don't push it." - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - -To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ http://www.mail-archive.com/discussion%40acfug.org/List hosted by http://www.fusionlink.com-
Re: [ACFUG Discuss] Another CFMAIL Problem
Or actually, Doug's explanation might be an instance of caching after all if the cache doesn't get cleared till the new version of the file is built...-Original Message- From: Peyton Todd <[EMAIL PROTECTED]> Sent: Nov 9, 2008 8:26 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem Doug, your guess that the email gets sent before the new PDF gets built rings true to me. It would explain the problem on my client's server, as well as the fact that it's not happening to me right now testing the system working on my own PC as localhost. It jogs my memory that my coworker experienced a similar problem back about 2001, when I was programming ColdFusion in New York City. (?New York City!?? Get a rope!)Dean, doesn't it make sense to you that the e-mail could get sent before the second version of the file gets built, so it merely picks up what it finds on the disk , namely, the earlier version of the file? Actually, come to think of it, that would not be an instance of caching. Ajas, I don't know, but it seems to me that saving the PDF into a SQL Server column might have the same problem as that described by Doug: if these operations can be performed asynchronously, then wouldn't it be possible that cfmail could grab the old value from the SQL Server column (presumably via its 'query=' parameter?) before my SQL Server update statement stuffs the new value into it?Howard, No, I didn't mean the office manager might get mixed up on which file is which - he's reasonably computer literate, and knows perfectly well that the one on top was sent later (Whoops! It just occurred to me that that might not always be true if there's a glitch in the e-mail process...). Anyway, though, what I did mean is that it's simply the older version of the file that gets attached to the e-mail. Your idea of sending a link seems like a good one, and I may try that but ... Naming the PDF by the Job Number instead of by the reporter's ID is necessary of regardless of whether I attach the file or send a link. In either case, I'd be writing the file to disk. If I were to delete any old copy beforehand, what are the chances that (if this asynchrous story is true) cfmail would fail to find the file when it looks for it and throw an error?Peyton-Original Message- From: Howard Fore <[EMAIL PROTECTED]> Sent: Nov 8, 2008 8:12 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem I think what he means is that if a recorder creates a file and sends it, then corrects it and sends again, the recipient could open the first one and think it is the most current version when it isn't. It wasn't identified as an issue by Peyton but I could see how it could cause someone an issue. My response to that would be to not mail the PDF as an attachment but rather email a link to the user. The link would either lead to a real PDF, stored on disk, or to a CFM file that generates the PDF when it is requested. That would get rid of any caching issue as the file requested is always the latest version. On Sat, Nov 8, 2008 at 6:19 PM, Dean H. Saxe [EMAIL PROTECTED] wrote: What "things" get asynchronous? If what you say is true, email would regularly go out without complete attachments. I think you're way off on this one. -- Howard Fore, [EMAIL PROTECTED]"The universe tends toward maximum irony. Don't push it." - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - -To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ http://www.mail-archive.com/discussion%40acfug.org/List hosted by http://www.fusionlink.com- -To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ http://www.mail-archive.com/discussion%40acfug.org/List hosted by http://www.fusionlink.com-
Re: [ACFUG Discuss] Another CFMAIL Problem
IF you can send a link to the server AND he always needs the latest version (and assuming it doesn't take long to generate the PDF) - I would send a link to a page that generates it on the fly every time and allow him to download that version when needed - as previously mentioned by Howard. This eliminates any issues to do with email latency (or the possibility of caching) and gives the opportunity to close some security holes created by leaving content in an unsecured location. Dawn On Sun, Nov 9, 2008 at 8:26 PM, Peyton Todd [EMAIL PROTECTED]wrote: Doug, your guess that the email gets sent before the new PDF gets built rings true to me. It would explain the problem on my client's server, as well as the fact that it's not happening to me right now testing the system working on my own PC as localhost. It jogs my memory that my coworker experienced a similar problem back about 2001, when I was programming ColdFusion in New York City. (?New York City!?? Get a rope!) Dean, doesn't it make sense to you that the e-mail could get sent before the second version of the file gets built, so it merely picks up what it finds on the disk , namely, the earlier version of the file? Actually, come to think of it, that would not be an instance of caching. Ajas, I don't know, but it seems to me that saving the PDF into a SQL Server column might have the same problem as that described by Doug: if these operations can be performed asynchronously, then wouldn't it be possible that cfmail could grab the old value from the SQL Server column (presumably via its 'query=' parameter?) before my SQL Server update statement stuffs the new value into it? Howard, No, I didn't mean the office manager might get mixed up on which file is which - he's reasonably computer literate, and knows perfectly well that the one on top was sent later (Whoops! It just occurred to me that that might not always be true if there's a glitch in the e-mail process...). Anyway, though, what I did mean is that it's simply the older version of the file that gets attached to the e-mail. Your idea of sending a link seems like a good one, and I may try that but ... Naming the PDF by the Job Number instead of by the reporter's ID is necessary of regardless of whether I attach the file or send a link. In either case, I'd be writing the file to disk. If I were to delete any old copy beforehand, what are the chances that (if this asynchrous story is true) cfmail would fail to find the file when it looks for it and throw an error? Peyton -Original Message- From: Howard Fore Sent: Nov 8, 2008 8:12 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem I think what he means is that if a recorder creates a file and sends it, then corrects it and sends again, the recipient could open the first one and think it is the most current version when it isn't. It wasn't identified as an issue by Peyton but I could see how it could cause someone an issue. My response to that would be to not mail the PDF as an attachment but rather email a link to the user. The link would either lead to a real PDF, stored on disk, or to a CFM file that generates the PDF when it is requested. That would get rid of any caching issue as the file requested is always the latest version. On Sat, Nov 8, 2008 at 6:19 PM, Dean H. Saxe [EMAIL PROTECTED]wrote: What things get asynchronous? If what you say is true, email would regularly go out without complete attachments. I think you're way off on this one. -- Howard Fore, [EMAIL PROTECTED] The universe tends toward maximum irony. Don't push it. - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?falogin.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Another CFMAIL Problem
Why not go ahead and use the job number, but when you're about to write the PDF to disk first check to see if there's already one with that name (initials and job number). If you find one then delete it, then create the new one. Is there some audit reason to keep the earlier version? On Fri, Nov 7, 2008 at 3:48 PM, Peyton Todd [EMAIL PROTECTED]wrote: One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. -- Howard Fore, [EMAIL PROTECTED] The universe tends toward maximum irony. Don't push it. - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Another CFMAIL Problem
Sounds like my original response. Check for the file first... Sent via BlackBerry by ATT -Original Message- From: Howard Fore [EMAIL PROTECTED] Date: Sat, 8 Nov 2008 09:19:22 To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem Why not go ahead and use the job number, but when you're about to write the PDF to disk first check to see if there's already one with that name (initials and job number). If you find one then delete it, then create the new one. Is there some audit reason to keep the earlier version? On Fri, Nov 7, 2008 at 3:48 PM, Peyton Todd [EMAIL PROTECTED]wrote: One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. -- Howard Fore, [EMAIL PROTECTED] The universe tends toward maximum irony. Don't push it. - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - N�r��yb�X��f�j���鮇���m q
Re: [ACFUG Discuss] Another CFMAIL Problem
I still don't get what it is you think is caching the file. Why not just delete the PDF as soon as you have emailed it? -dhs -- Dean H. Saxe [EMAIL PROTECTED] On Nov 8, 2008, at 9:52 AM, [EMAIL PROTECTED] wrote: Sounds like my original response. Check for the file first... Sent via BlackBerry by ATT From: Howard Fore [EMAIL PROTECTED] Date: Sat, 8 Nov 2008 09:19:22 -0500 To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem Why not go ahead and use the job number, but when you're about to write the PDF to disk first check to see if there's already one with that name (initials and job number). If you find one then delete it, then create the new one. Is there some audit reason to keep the earlier version? On Fri, Nov 7, 2008 at 3:48 PM, Peyton Todd [EMAIL PROTECTED] wrote: One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. -- Howard Fore, [EMAIL PROTECTED] The universe tends toward maximum irony. Don't push it. - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink -
Re: [ACFUG Discuss] Another CFMAIL Problem
It's just that caching is the only explanation I can think of, and if that's the reason, then deleting the earlier version of the file would do no good if the cached version is what's being sent. On the other hand, I have not verified that indeed the second version is indeed being created, so more research is necessary...-Original Message- From: "Dean H. Saxe" <[EMAIL PROTECTED]> Sent: Nov 8, 2008 10:09 AM To: "discussion@acfug.org" <discussion@acfug.org> Subject: Re: [ACFUG Discuss] Another CFMAIL Problem I still don't get what it is you think is caching the file. Why not just delete the PDF as soon as you have emailed it?-dhs--Dean H. Saxe[EMAIL PROTECTED]On Nov 8, 2008, at 9:52 AM, [EMAIL PROTECTED] wrote: Sounds like my original response. Check for the file first...Sent via BlackBerry by ATTFrom: "Howard Fore" [EMAIL PROTECTED]Date: Sat, 8 Nov 2008 09:19:22 -0500To: discussion@acfug.orgSubject: Re: [ACFUG Discuss] Another CFMAIL Problem Why not go ahead and use the job number, but when you're about to write the PDF to disk first check to see if there's already one with that name (initials and job number). If you find one then delete it, then create the new one. Is there some audit reason to keep the earlier version?On Fri, Nov 7, 2008 at 3:48 PM, Peyton Todd [EMAIL PROTECTED] wrote: One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead.-- Howard Fore, [EMAIL PROTECTED]"The universe tends toward maximum irony. Don't push it." - Jeff Atwood -To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ http://www.mail-archive.com/discussion%40acfug.org/List hosted by FusionLink- -To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ http://www.mail-archive.com/discussion%40acfug.org/List hosted by http://www.fusionlink.com-
Re: [ACFUG Discuss] Another CFMAIL Problem
caching would be at the webserver level with respect to this. My guess is the email gets sent prior to the new PDF being completed. Emails are queued and file saves involve file system work-time, so things get a bit asynchronous. Even with unique file naming schems, this can be a issue. Try the unique naming approach, the possible error would involve the email engine not being able to find the file when the email is to be sent. If this doesn't work reliably, I'd look at inline attachments. This latter approach would put the PDF in the email itself as a attachment wiht the added bonus of not needing to be placed in the webroot. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Sat, Nov 8, 2008 at 10:45 AM, Peyton Todd [EMAIL PROTECTED]wrote: It's just that caching is the only explanation I can think of, and if that's the reason, then deleting the earlier version of the file would do no good if the cached version is what's being sent. On the other hand, I have not verified that indeed the second version is indeed being created, so more research is necessary... -Original Message- From: Dean H. Saxe Sent: Nov 8, 2008 10:09 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem I still don't get what it is you think is caching the file. Why not just delete the PDF as soon as you have emailed it? -dhs -- Dean H. Saxe [EMAIL PROTECTED] On Nov 8, 2008, at 9:52 AM, [EMAIL PROTECTED] wrote: Sounds like my original response. Check for the file first... Sent via BlackBerry by ATT -- *From*: Howard Fore [EMAIL PROTECTED] *Date*: Sat, 8 Nov 2008 09:19:22 -0500 *To*: discussion@acfug.org *Subject*: Re: [ACFUG Discuss] Another CFMAIL Problem Why not go ahead and use the job number, but when you're about to write the PDF to disk first check to see if there's already one with that name (initials and job number). If you find one then delete it, then create the new one. Is there some audit reason to keep the earlier version? On Fri, Nov 7, 2008 at 3:48 PM, Peyton Todd [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. -- Howard Fore, [EMAIL PROTECTED][EMAIL PROTECTED] The universe tends toward maximum irony. Don't push it. - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?falogin.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Another CFMAIL Problem
First things first. What Dean suggested is correct. You first need to look security wise. Its not a wise idea to leave things sitting there in the open and waiting for something to happen. Anyway, thats your choice how you decide to plan your application. Now to the actual issue, do you have any database access? If yes, for example, if its sql server, you could have identity column which is unique and which could be tied to your client and job number. so simple query and u could get the pdf file which could be just identitycolumnnumber.pdf or client+identitycolumn.pdf or client+identitycolumn+jobno.pdf. In the same table, you could have pdf_content column which saves pdf content, so this way, you can store your pdf content and create the pdf on the fly at any time. In your application, you could have batch_pdf folder and store pdfs there, and find file (based of database identity column or job no or client name etc) and attach it to the mail. By storing pdf content, you dont need to to store pdfs and if you do save, you could delete and not worry, since you have content. This is always good for audit purposes. Hope that helps. Ajas Mohammed. On Sat, Nov 8, 2008 at 5:20 PM, Douglas Knudsen [EMAIL PROTECTED]wrote: caching would be at the webserver level with respect to this. My guess is the email gets sent prior to the new PDF being completed. Emails are queued and file saves involve file system work-time, so things get a bit asynchronous. Even with unique file naming schems, this can be a issue. Try the unique naming approach, the possible error would involve the email engine not being able to find the file when the email is to be sent. If this doesn't work reliably, I'd look at inline attachments. This latter approach would put the PDF in the email itself as a attachment wiht the added bonus of not needing to be placed in the webroot. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Sat, Nov 8, 2008 at 10:45 AM, Peyton Todd [EMAIL PROTECTED]wrote: It's just that caching is the only explanation I can think of, and if that's the reason, then deleting the earlier version of the file would do no good if the cached version is what's being sent. On the other hand, I have not verified that indeed the second version is indeed being created, so more research is necessary... -Original Message- From: Dean H. Saxe Sent: Nov 8, 2008 10:09 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem I still don't get what it is you think is caching the file. Why not just delete the PDF as soon as you have emailed it? -dhs -- Dean H. Saxe [EMAIL PROTECTED] On Nov 8, 2008, at 9:52 AM, [EMAIL PROTECTED] wrote: Sounds like my original response. Check for the file first... Sent via BlackBerry by ATT -- *From*: Howard Fore [EMAIL PROTECTED] *Date*: Sat, 8 Nov 2008 09:19:22 -0500 *To*: discussion@acfug.org *Subject*: Re: [ACFUG Discuss] Another CFMAIL Problem Why not go ahead and use the job number, but when you're about to write the PDF to disk first check to see if there's already one with that name (initials and job number). If you find one then delete it, then create the new one. Is there some audit reason to keep the earlier version? On Fri, Nov 7, 2008 at 3:48 PM, Peyton Todd [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. -- Howard Fore, [EMAIL PROTECTED][EMAIL PROTECTED] The universe tends toward maximum irony. Don't push it. - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?falogin.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform
Re: [ACFUG Discuss] Another CFMAIL Problem
What things get asynchronous? If what you say is true, email would regularly go out without complete attachments. I think you're way off on this one. -dhs -- Dean H. Saxe [EMAIL PROTECTED] On Nov 8, 2008, at 5:20 PM, Douglas Knudsen [EMAIL PROTECTED] wrote: caching would be at the webserver level with respect to this. My guess is the email gets sent prior to the new PDF being completed. Emails are queued and file saves involve file system work-time, so things get a bit asynchronous. Even with unique file naming schems, this can be a issue. Try the unique naming approach, the possible error would involve the email engine not being able to find the file when the email is to be sent. If this doesn't work reliably, I'd look at inline attachments. This latter approach would put the PDF in the email itself as a attachment wiht the added bonus of not needing to be placed in the webroot. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Sat, Nov 8, 2008 at 10:45 AM, Peyton Todd [EMAIL PROTECTED] wrote: It's just that caching is the only explanation I can think of, and if that's the reason, then deleting the earlier version of the file would do no good if the cached version is what's being sent. On the other hand, I have not verified that indeed the second version is indeed being created, so more research is necessary... -Original Message- From: Dean H. Saxe Sent: Nov 8, 2008 10:09 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem I still don't get what it is you think is caching the file. Why not just delete the PDF as soon as you have emailed it? -dhs -- Dean H. Saxe [EMAIL PROTECTED] On Nov 8, 2008, at 9:52 AM, [EMAIL PROTECTED] wrote: Sounds like my original response. Check for the file first... Sent via BlackBerry by ATT From: Howard Fore [EMAIL PROTECTED] Date: Sat, 8 Nov 2008 09:19:22 -0500 To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem Why not go ahead and use the job number, but when you're about to write the PDF to disk first check to see if there's already one with that name (initials and job number). If you find one then delete it, then create the new one. Is there some audit reason to keep the earlier version? On Fri, Nov 7, 2008 at 3:48 PM, Peyton Todd [EMAIL PROTECTED] wrote: One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. -- Howard Fore, [EMAIL PROTECTED] The universe tends toward maximum irony. Don't push it. - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?falogin.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink -
Re: [ACFUG Discuss] Another CFMAIL Problem
I think what he means is that if a recorder creates a file and sends it, then corrects it and sends again, the recipient could open the first one and think it is the most current version when it isn't. It wasn't identified as an issue by Peyton but I could see how it could cause someone an issue. My response to that would be to not mail the PDF as an attachment but rather email a link to the user. The link would either lead to a real PDF, stored on disk, or to a CFM file that generates the PDF when it is requested. That would get rid of any caching issue as the file requested is always the latest version. On Sat, Nov 8, 2008 at 6:19 PM, Dean H. Saxe [EMAIL PROTECTED]wrote: What things get asynchronous? If what you say is true, email would regularly go out without complete attachments. I think you're way off on this one. -- Howard Fore, [EMAIL PROTECTED] The universe tends toward maximum irony. Don't push it. - Jeff Atwood - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Another CFMAIL Problem
You could always check for existence of the file and create a unique filename if it already exists. From: Peyton Todd [EMAIL PROTECTED] To: discussion@acfug.org Sent: Friday, November 7, 2008 3:48:58 PM Subject: [ACFUG Discuss] Another CFMAIL Problem The web page I'm having a problem with builds a PDF document and attaches that to an e-mail. The problem is that the user can do this for successive job numbers one after the other (it's a site for court reporters to report back to the company that sent them on a job). I have been naming the PDF with the reporter's initials (e.g. PHT.pdf if I were one of them), and the bug is that frequently the PDF for the previous job gets attached instead of the PDF just built. One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. Here is the CFMAIL tag (names changed to protect the guilty): cfmail from=#sendfrom# to=#sendto# subject=Job #Session.sJobNo# has been reported by #Session.UserName# server=abc.def.net username=[EMAIL PROTECTED] password=blahblah mimeattach=c:/Inetpub/wwwroot/Reporters/#Session.UserName#.PDF Report completed: See Attached Job Sheet /cfmail The code which buildt the PDF attached by the code just above attempts to ensure that the PDF for the job just reported gets overwritten, and doesn't get cached, but evidently does not succeed: html head titlePost-Job Reporting/title meta http-equiv=Content-Type content=text/html; charset=iso-8859-1/ cfoutputMETA HTTP-EQUIV=Expires CONTENT=#GetHTTPTimeString(NOW())#//cfoutput META HTTP-EQUIV=Pragma CONTENT=no-cache/ META HTTP-EQUIV=cache-control VALUE=no-cache, no-store,must-revalidate/ LINK REL=STYLESHEET TYPE=text/css HREF=ACRGA.css/ /head body cfset filename = UCase(Session.UserName) .PDF cfdocument format=PDF filename=#filename# overwrite=yes TABLE border=1 width=100% style=border-style:groove; font-size:14pt; TRTD table width=100% cfoutput tr td valign=middle align=left etc., etc.,... Any ideas as to what might be wrong? - Peyton - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Another CFMAIL Problem
Thanks, Shawn, but I'm hoping there's a simpler way, such as some parm I can set, or that my code intending to prevent caching is inadequate...-Original Message- From: shawn gorrell <[EMAIL PROTECTED]> Sent: Nov 7, 2008 3:55 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem You could always check for existence of the file and create a unique filename if it already exists. From: Peyton Todd [EMAIL PROTECTED]To: discussion@acfug.orgSent: Friday, November 7, 2008 3:48:58 PMSubject: [ACFUG Discuss] Another CFMAIL Problem The web page I'm having a problem with builds a PDF document and attaches that to an e-mail. The problem is that the user can do this for successive job numbers one after the other (it's a site for court reporters to report back to the company that sent them on a job). I have been naming the PDF with the reporter's initials (e.g. PHT.pdf if I were one of them), and the bug is that frequently the PDF for the previous job gets attached instead of the PDF just built. One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead.Here is the CFMAIL tag (names changed to protect the guilty):cfmail from="#sendfrom#" to="#sendto#" subject="Job #Session.sJobNo# has been reported by #Session.UserName#" server="abc.def.net" username="[EMAIL PROTECTED]" password="blahblah" mimeattach="c:/Inetpub/wwwroot/Reporters/#Session.UserName#.PDF" Report completed: See Attached Job Sheet /cfmailThe code which buildt the PDF attached by the code just above attempts to ensure that the PDF for the job just reported gets overwritten, and doesn't get cached, but evidently does not succeed:htmlheadtitlePost-Job Reporting/titlemeta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/cfoutputMETA HTTP-EQUIV="Expires" CONTENT="#GetHTTPTimeString(NOW())#"//cfoutputMETA HTTP-EQUIV="Pragma" CONTENT="no-cache"/META HTTP-EQUIV="cache-control" VALUE="no-cache, no-store,must-revalidate"/LINK REL="STYLESHEET" TYPE="text/css" HREF=""//headbodycfset filename = UCase(Session.UserName) ".PDF" cfdocument format="PDF" filename="#filename#" overwrite="yes"TABLE border="1" width="100%" style="border-style:groove; font-size:14pt;" TRTD table width="100%" cfoutput tr td valign="middle" align="left"etc., etc.,...Any ideas as to what might be wrong?- Peyton-To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ http://www.mail-archive.com/discussion%40acfug.org/List hosted by http://www.fusionlink.com- - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - -To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformFor more info, see http://www.acfug.org/mailinglistsArchive @ http://www.mail-archive.com/discussion%40acfug.org/List hosted by http://www.fusionlink.com-
Re: [ACFUG Discuss] Another CFMAIL Problem
Why are you dropping these files in the webroot? Now they are exposed for anyone to download... (yes, I recognize this has nothing to do with your question...) Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy? --Gandhi On Nov 7, 2008, at 4:01 PM, Peyton Todd wrote: Thanks, Shawn, but I'm hoping there's a simpler way, such as some parm I can set, or that my code intending to prevent caching is inadequate... -Original Message- From: shawn gorrell Sent: Nov 7, 2008 3:55 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem You could always check for existence of the file and create a unique filename if it already exists. From: Peyton Todd [EMAIL PROTECTED] To: discussion@acfug.org Sent: Friday, November 7, 2008 3:48:58 PM Subject: [ACFUG Discuss] Another CFMAIL Problem The web page I'm having a problem with builds a PDF document and attaches that to an e-mail. The problem is that the user can do this for successive job numbers one after the other (it's a site for court reporters to report back to the company that sent them on a job). I have been naming the PDF with the reporter's initials (e.g. PHT.pdf if I were one of them), and the bug is that frequently the PDF for the previous job gets attached instead of the PDF just built. One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. Here is the CFMAIL tag (names changed to protect the guilty): cfmail from=#sendfrom# to=#sendto# subject=Job #Session.sJobNo# has been reported by #Session.UserName# server=abc.def.net username=[EMAIL PROTECTED] password=blahblah mimeattach=c:/Inetpub/wwwroot/Reporters/#Session.UserName#.PDF Report completed: See Attached Job Sheet /cfmail The code which buildt the PDF attached by the code just above attempts to ensure that the PDF for the job just reported gets overwritten, and doesn't get cached, but evidently does not succeed: html head titlePost-Job Reporting/title meta http-equiv=Content-Type content=text/html; charset=iso-8859-1/ cfoutputMETA HTTP-EQUIV=Expires CONTENT=#GetHTTPTimeString(NOW())#//cfoutput META HTTP-EQUIV=Pragma CONTENT=no-cache/ META HTTP-EQUIV=cache-control VALUE=no-cache, no-store,must- revalidate/ LINK REL=STYLESHEET TYPE=text/css HREF=ACRGA.css/ /head body cfset filename = UCase(Session.UserName) .PDF cfdocument format=PDF filename=#filename# overwrite=yes TABLE border=1 width=100% style=border-style:groove; font-size: 14pt; TRTD table width=100% cfoutput tr td valign=middle align=left etc., etc.,... Any ideas as to what might be wrong? - Peyton - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Another CFMAIL Problem
Pure laziness, Dean. It's not information anyone cares about. Now that you have my attention, though, how exactly would someone do that? Even better, how can I prevent the PDF that gets built first from being cached, assuming that's what's happening? -Original Message- From: Dean H. Saxe [EMAIL PROTECTED] Sent: Nov 7, 2008 4:17 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem Why are you dropping these files in the webroot? Now they are exposed for anyone to download... (yes, I recognize this has nothing to do with your question...) Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy? --Gandhi On Nov 7, 2008, at 4:01 PM, Peyton Todd wrote: Thanks, Shawn, but I'm hoping there's a simpler way, such as some parm I can set, or that my code intending to prevent caching is inadequate... -Original Message- From: shawn gorrell Sent: Nov 7, 2008 3:55 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem You could always check for existence of the file and create a unique filename if it already exists. From: Peyton Todd [EMAIL PROTECTED] To: discussion@acfug.org Sent: Friday, November 7, 2008 3:48:58 PM Subject: [ACFUG Discuss] Another CFMAIL Problem The web page I'm having a problem with builds a PDF document and attaches that to an e-mail. The problem is that the user can do this for successive job numbers one after the other (it's a site for court reporters to report back to the company that sent them on a job). I have been naming the PDF with the reporter's initials (e.g. PHT.pdf if I were one of them), and the bug is that frequently the PDF for the previous job gets attached instead of the PDF just built. One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. Here is the CFMAIL tag (names changed to protect the guilty): cfmail from=#sendfrom# to=#sendto# subject=Job #Session.sJobNo# has been reported by #Session.UserName# server=abc.def.net username=[EMAIL PROTECTED] password=blahblah mimeattach=c:/Inetpub/wwwroot/Reporters/#Session.UserName#.PDF Report completed: See Attached Job Sheet /cfmail The code which buildt the PDF attached by the code just above attempts to ensure that the PDF for the job just reported gets overwritten, and doesn't get cached, but evidently does not succeed: html head titlePost-Job Reporting/title meta http-equiv=Content-Type content=text/html; charset=iso-8859-1/ cfoutputMETA HTTP-EQUIV=Expires CONTENT=#GetHTTPTimeString(NOW())#//cfoutput META HTTP-EQUIV=Pragma CONTENT=no-cache/ META HTTP-EQUIV=cache-control VALUE=no-cache, no-store,must- revalidate/ LINK REL=STYLESHEET TYPE=text/css HREF=ACRGA.css/ /head body cfset filename = UCase(Session.UserName) .PDF cfdocument format=PDF filename=#filename# overwrite=yes TABLE border=1 width=100% style=border-style:groove; font-size: 14pt; TRTD table width=100% cfoutput tr td valign=middle align=left etc., etc.,... Any ideas as to what might be wrong? - Peyton - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail
Re: [ACFUG Discuss] Another CFMAIL Problem
If it's somewhere in the webroot, they just have to request it. If they know it exists, of course. And if exists with my username, I bet I can guess other username too! Unfortunately I have no answer to the caching question. -dhs -- Dean H. Saxe [EMAIL PROTECTED] On Nov 7, 2008, at 6:25 PM, Peyton Todd [EMAIL PROTECTED] wrote: Pure laziness, Dean. It's not information anyone cares about. Now that you have my attention, though, how exactly would someone do that? Even better, how can I prevent the PDF that gets built first from being cached, assuming that's what's happening? -Original Message- From: Dean H. Saxe [EMAIL PROTECTED] Sent: Nov 7, 2008 4:17 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem Why are you dropping these files in the webroot? Now they are exposed for anyone to download... (yes, I recognize this has nothing to do with your question...) Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy? --Gandhi On Nov 7, 2008, at 4:01 PM, Peyton Todd wrote: Thanks, Shawn, but I'm hoping there's a simpler way, such as some parm I can set, or that my code intending to prevent caching is inadequate... -Original Message- From: shawn gorrell Sent: Nov 7, 2008 3:55 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Another CFMAIL Problem You could always check for existence of the file and create a unique filename if it already exists. From: Peyton Todd [EMAIL PROTECTED] To: discussion@acfug.org Sent: Friday, November 7, 2008 3:48:58 PM Subject: [ACFUG Discuss] Another CFMAIL Problem The web page I'm having a problem with builds a PDF document and attaches that to an e-mail. The problem is that the user can do this for successive job numbers one after the other (it's a site for court reporters to report back to the company that sent them on a job). I have been naming the PDF with the reporter's initials (e.g. PHT.pdf if I were one of them), and the bug is that frequently the PDF for the previous job gets attached instead of the PDF just built. One solution I thought of is simply to use the job number as the name of the PDF. This would guarantee that each next one built is different. But then it occurred to me that if the user reports a job, then realizes he made a mistake, corrects it, and sends the report again for the same job, there's a danger that the earlier mistaken version would get sent instead. Here is the CFMAIL tag (names changed to protect the guilty): cfmail from=#sendfrom# to=#sendto# subject=Job #Session.sJobNo# has been reported by #Session.UserName# server=abc.def.net username=[EMAIL PROTECTED] password=blahblah mimeattach=c:/Inetpub/wwwroot/Reporters/#Session.UserName#.PDF Report completed: See Attached Job Sheet /cfmail The code which buildt the PDF attached by the code just above attempts to ensure that the PDF for the job just reported gets overwritten, and doesn't get cached, but evidently does not succeed: html head titlePost-Job Reporting/title meta http-equiv=Content-Type content=text/html; charset=iso-8859-1/ cfoutputMETA HTTP-EQUIV=Expires CONTENT=#GetHTTPTimeString(NOW())#//cfoutput META HTTP-EQUIV=Pragma CONTENT=no-cache/ META HTTP-EQUIV=cache-control VALUE=no-cache, no-store,must- revalidate/ LINK REL=STYLESHEET TYPE=text/css HREF=ACRGA.css/ /head body cfset filename = UCase(Session.UserName) .PDF cfdocument format=PDF filename=#filename# overwrite=yes TABLE border=1 width=100% style=border-style:groove; font- size: 14pt; TRTD table width=100% cfoutput tr td valign=middle align=left etc., etc.,... Any ideas as to what might be wrong? - Peyton - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com
