email w/ IWP/xslt unsolved...

[sleepinggypsy]

Martin and board, one slight problem w/ the emailing thing using IWP and xslt. The problem is that if user has pop-up blockers there is no way to dynamically determine if the email was sent? In other words, even though FMSA now gives a notice that "the script attempted to open a url...", the user doesn't get any further indication that the email was not sent. Stephen from FMWebschool posted a php example that used php (http://fmforums.com/forum/showpost.php?post/194290/). IWP called a php page that sent the email. If the email was actually sent, it retuned a successphp page, if not an error php page. The benefit of this is that since php controlled the actual email, success and error pages were generated. The user and developer wouldn't have to rely solely on the generic pop-up blocker message. So, my question is, can this be replicated using xslt and IWP?

[Hope Ray]

-

-

-

An e-mail has been sent to your manager,

Once your manager has sent an approval e-mail to Customer Service, your order willl be processed.

Processing will not be initiated until manager's approval is received.

If you have any questions regarding your request, you may contact Customer Service at this phone number

-

An e-mail was not sent. Please contact Customer Service at this phone number regarding your request!

-

Return to Home

[Martin Brändle]

Hope,

thank you. I had posted a quick and dirty example some time ago: http://www.fmforums.com/forum/showtopic.php?tid/173779/

His problem is that a popup window opens in IWP if one clicks on the button with OpenURL script step.

There is another solution with PHP made by Stephen Knight, but up to now I did not have the time to have a look at it.

Another problem, however is, that we have several threads scattered among various forums here, at least 4 started by sleepinggypsy. And he just leans back and expects solutions from others ...

[sleepinggypsy]

Martin, that statement is totally unfair. i worked and worked on trying to figure the xml thing out till my head was spinning. I was getting posts to use xml, posts to use plug-ins, posts to use php... I read the CWP publishing manuals. I tried multiple downloads of your zip file. I could literally go on an on! I am brand new to CWP and even using these forums. I started from ground zero. Finally, once I got your solution working from my perspective, I went as far as taking down one of my databases at Point in Space, so as to utilize my server space to host the solution for others to view! It seemed like the least I could do. I then went on to post a thank you on the forum for all your help. It was at this point i recognized what was happening with the pop-up blockers and the potential problem for me and other users. I asked for more help. No reply. I emailed you and offered to pay you to consult. No reply. You have been so gracious to date. Thank you once again for your help. Not sure what else I can say. I'll continue to try to utilize the board without your help from here on and try to minimize may various postings. My overall hope is that I can somehow reciprocate to CWP newbies like myself once I have finally learned and understand this.

[Martin Brändle]

I'm sorry for that. I wanted to see if you did yourself continue with the solution, that's why I was a little provocative. Have you tried the PHP solution? Is there a popup window used as well? I did not see one in the FMWebschool video, and Stephen did not answer my (implicit) question if there is one. If there is one, then the problem clearly lies at IWP.

My way here in this forum is to post sometimes little examples that demonstrate a certain function or show a trick, but not a complete solution. I think it is better to learn from little examples, and then to be able to build up a code basis that can be reused.

BTW, I did not get an e-mail from you. Either you sent it to the wrong address, or our spam blockers filtered it. I do sometimes help here in the forum and learn also a lot from others, but I am not allowed to do that on a commercial basis. So it is my free (night or weekend) time that is spent here, and that's why it sometimes takes time until an answer might come.

Your struggling with CWP however shows, that the standard documentation from FMI (e.g. the CWP Guide) is not enough for beginners. The CWP Guide is ok for those that already had some experience with CDML (especially Appendix C is excellent) and already know some basics of XSLT. The site assistant is ok, but it generates already pretty complex XSLT code.

A good book to start with XSLT is

XSLT Programmer's Reference by Michael Kay, Wiley Publishing (a must-have, the XSLT bible)

and there is a good page by FMI with a starter solution at

http://www.filemaker.com/developers/resources/cwp.html

[sleepinggypsy]

i understand where you're coming from. Here's the bottom line. I have the xls file and the openurl script step from FMP working thanks to you. Obviously a more elegant solution would be to have feedback if the email doesn't get sent or a success page when it does. At this point, beggars can't be choosers so I'm willing to deal with what I have until I learn this stuff. WHICH I WILL!

I have moved on (by myself) to the 2nd part of my question which is passing a link in the email that when clicked will run a script. Since that seems beyond my capabilities, I have figured out how to create an xml query to simply edit a record in my db. In my case, it will simply change the status field to active and I will manually run a script from within FMP. However, when I try to put this xml query in place of the generic text in the body of your xls example file, it results in an error and the email isn't sent. I've attached the file just in case you're still willing to help me. BTW, I'd like to pass the current recid, not a static record id (1584) as I have in my file.

A second, more significant problem occured to me when I tested this xml query directly in the URL bar of my browser: anyone could modify any record of my database by simply changing the record ID that is passed! So even, if I can get this xml query to pass via the email being sent, I am back at square one at figuring out how to prevent unauthorized modifications of my db.

test_emailiwp.xsl.zip

[Martin Brändle]

To your first question: Feedback is possible. I will send back a modified file soon.

To your second question: I will have a look at it.

[Martin Brändle]

Both questions can be answered by standard techniques I also use in some of our XML/XSLT webpages and within our databases.

You find a new test_emailiwp_v2.zip in the attachment with a modified test_emailiwp.fp7, a modified test_emailiwp.xsl, and a new test_emailiwpconfirm.xsl . You'll see it goes more and more in the direction of CWP, and from the 100s to the 1000s.

The test_emailiwp.fp7 is extended by 3 fields:

Status - confirmation status

cookie - a random number. The number must be random due to security reasons. Never use a value that can be guessed.

email_sent - a text field initially set to "no"

In addition the accounts were changed:

Admin account with full access (no password set at present)

Guest account with read access only, and IWP access as well as XSLT access allowed

XML account with a password, allows only XML access, but also to write

Question 1: Popup window blocking.

If popup window blocking is turned on in the browser, nothing happens and you get the well known error message. The field email_sent remains at "no".

If popup window blocking is turned off, the OpenURL script calls test_emailiwp.xsl as before, which tries to send the e-mail. If successful, email_sent is set to "yes" by using the XSLT document() function which sends an XML query to switch the value. For this the XML account and the password is needed. If not successful, the popup window stays open and displays an error message.

Important The document() function must work and must be tested before you go into production. Then switch to XSLT production mode in your WPE Admin Console, otherwise the password will get visible in the next error message if something wrong happens with the query in document().

Question 2: Security.

For the problem of an editable database, see the solution with the XML account.

In addition, the problem of URL spoofing can be solved with a (session) cookie.

test_emailiwp.xsl writes a cookie into the user's browser, which persists for some time (in the example file, for 24 hours = 86400 seconds)

Now, when the user confirms by clicking the link sent to him in the e-mail, he calls test_emailiwpconfim.xsl . The only parameter that is passed is the id stored in the record.

This page does first a search of "his" record. Look at page 55 of the CWP Guide, "Using statically defined query commands and query parameters", to see how this technique works.

Next it reads the previously saved cookie from his browser and compares with the cookie value in the record. If they are the same, then fine, and with a document() XML query the status field is set. Finally the cookie is removed.

Otherwise, if he tries either to spoof the URL or the cookie, then he gets his surprise :bang:

test_emailiwp_v2.zip