using a revlet to export text to a file

[reelstuff]

I am looking into how I might export text as a file from a revlet.

I was thinking that I could do this

Code: Select all

on exportRoutine
    get the text of fld "testing2"
   put it into myVar
   put pathData into URL ("file:" & it & "myfile.php")
end exportRoutine

but I would still need to find a way to define the location of it, or where to save the file on the server,

anyone know of a good source of info or a white paper on this,

thanks for any help.

Tim

[FourthWorld]

http://revjournal.com/blog.irv?pid=1253992718.569667

[reelstuff]

Thanks for that, information,

I really do not want to use CGI when PHP is easier and faster, and I do not have to set anything up, but I do appreciate your post,

So there is no mechanism, to use this plugin
in a secure area for use by a server side language this is well,
strange to me.

so there is no real way to use the plugin to do some of the most common things in PHP?

Code: Select all

else if(isset($_GET['function']))

[mwieder]

Are you wanting to save files on the server where the revlet was launched or on the client browser's machine?

[reelstuff]

Yes, on the server
I was looking for a way to change the settings of a PHP file,

Code: Select all

$variable=0 // 0 for yes 1 for no

so I would use a combo box to choose the value I wanted to change, and then save that as a PHP file,

basically creating a PHP editor online using a revlet, in a secure admin area,

[FourthWorld]

so there is no real way to use the plugin to do some of the most common things in PHP?

Plugins and PHP work at opposite ends of the communication: a Revlet comes alive only on the client, while PHP is alive only on the server.

The Revlet can (with the user's permission) alter things on the user's drive, something PHP can't do.

And likewise, PHP can easily alter things on the server, but unless you set up a special mechanism for it you're likely very glad folks can't alter files on your server from their browser.

That "special mechanism" need not be a CGI (and CGI's need not be slow; the Rev engine is small enough that I'd be surprised if running a template through its merge function benchmarked much slower than a standard PHP installation). Revlets support many common client-server web communications methods, including FTP and rolling your own with sockets.

If you prefer PHP for your server-side processing (or mod_perl or anything else you like), you could write the server stuff there and call it from the client side in your Revlet.

[Philhold]

Hi Tim,

I've just re read what I have written below and it sounds a bit more harsh than I mean it to. I honestly think that you need to get your understanding of how server side scripts work and communicate with client side "forms" before you start trying to write to files on the server.

What you are proposing to do in the way you describe is a massive security risk.

You seem to fundamentally misunderstand how a client and server work.
The communication between the users browser or application and the PHP server sends variables as key-value pairs. The job of the browser form or RunRev application form is to collect those key-value pairs and send them to a script file on the server, the script file then decodes the key value pairs and validates them, to ensure that they do not contain malicious code, and then it does stuff with the now clean variables and then can send a message back to the user and/or store something on the server. Storage can be in text files or some sort of database but it is the PHP script (or Perl Script) or whatever on the server that does the saving of the data. This user generated saved data must IMHO only be used as variables by a server script and these must be revalidated when they are used.

In HTTP communication Runtime Revolution can only send variables to your server side script.

Alternatively if the application you are writing is only for use by people who have password protected ftp access to your server then you could have RunRev create a file locally and then have it drop that file onto the server using ftp.

I hope that this helps.

Cheers

Phil

[reelstuff]

so there is no real way to use the plugin to do some of the most common things in PHP?

Plugins and PHP work at opposite ends of the communication: a Revlet comes alive only on the client, while PHP is alive only on the server.

The Revlet can (with the user's permission) alter things on the user's drive, something PHP can't do.

And likewise, PHP can easily alter things on the server, but unless you set up a special mechanism for it you're likely very glad folks can't alter files on your server from their browser.

That "special mechanism" need not be a CGI (and CGI's need not be slow; the Rev engine is small enough that I'd be surprised if running a template through its merge function benchmarked much slower than a standard PHP installation). Revlets support many common client-server web communications methods, including FTP and rolling your own with sockets.

If you prefer PHP for your server-side processing (or mod_perl or anything else you like), you could write the server stuff there and call it from the client side in your Revlet.

Thanks for taking time to reply, I appreciate that, and yes I agree with you, I was hoping to find a better use than just a client side script, see what I really want is the irev capabilities, embodied into the revlet,

So I push for different uses, because I do not see the use of the revlet as a client only use, because it is a container, that can communicate, it should be able to do more than just sit there as a client request, leaving aside the issue of security because we all know that you can only put so strong a lock on the door, someone will come along and break it eventually.

I will consider, your comments a little more, I just wish that there were not so many limits on the use of this resource and the irev tagging anyway thanks, for posting, I can see that it is time to abandon ship

[reelstuff]

Hi Tim,

I've just re read what I have written below and it sounds a bit more harsh than I mean it to. I honestly think that you need to get your understanding of how server side scripts work and communicate with client side "forms" before you start trying to write to files on the server.

Not at all my friend, my comments were meant to challenge the developers in the forum as well as the creators of the plugin to create a different use case one that could be used to do admin tasks on the server, since we have the ability to use passwords on a revlet, (or at least one would hope so) it could be made moderatly more secure than a PHP page, which as you see daily people break into from time to time to do bad things.

What you are proposing to do in the way you describe is a massive security risk.

not really, but I do understand your thinking, I think of the use of revlets as a two way street not a client only street, in my mind the revet can and should be used as any other language is used, PHP uses a browser to login into a wordpress website, is it not? so then why do we see the revlet as a client only vehicle, do you see what I am saying?

You seem to fundamentally misunderstand how a client and server work.
The communication between the users browser or application and the PHP server sends variables as key-value pairs. The job of the browser form or RunRev application form is to collect those key-value pairs and send them to a script file on the server, the script file then decodes the key value pairs and validates them, to ensure that they do not contain malicious code, and then it does stuff with the now clean variables and then can send a message back to the user and/or store something on the server. Storage can be in text files or some sort of database but it is the PHP script (or Perl Script) or whatever on the server that does the saving of the data. This user generated saved data must IMHO only be used as variables by a server script and these must be revalidated when they are used.

I understand it very well, as well I understand your thinking on this too, but I hope that the revlet will not be so constrained as we have discussed it, I hope it can evolve into a more productive tool, because if it is as described then it is not much of a tool, and I think that is not the case at all.

Thanks for taking time to reply, I really do appreciate that, I often look for new ways to use old technology in this case new technology, as is so often the case in discussions very often people miss understand and so react in a negative way, but I believe that if not for good discussions, (and I believe this is one of those things() then we would be sad indeed.

have a very pleasant day.



In HTTP communication Runtime Revolution can only send variables to your server side script.

Alternatively if the application you are writing is only for use by people who have password protected ftp access to your server then you could have RunRev create a file locally and then have it drop that file onto the server using ftp.

I hope that this helps.

Cheers

Phil

[FourthWorld]

...I push for different uses, because I do not see the use of the revlet as a client only use, because it is a container, that can communicate, it should be able to do more than just sit there as a client request, leaving aside the issue of security because we all know that you can only put so strong a lock on the door, someone will come along and break it eventually.

Your inspiration is a good one, and can be realized within the bounds of reasonable security. In fact, given the confines of the browser, there is simply no other way.

Another option is to consider moving your project outside the browser, using a standalone which would give you all the connectivity you enjoy with the web and other Internet protocols, but also give you all the freedom desktop apps enjoy.

I have an article outlining some of the benefits of this model here:
http://www.fourthworld.com/embassy/arti ... tapps.html

It may not serve your needs for the project at hand, but would provide what you're looking for unencumbered by the limitations of the browser.

I will consider, your comments a little more, I just wish that there were not so many limits on the use of this resource and the irev tagging anyway thanks, for posting, I can see that it is time to abandon ship

A plugin is a plugin. You could move to Flash, Java, JavaScript, or any other client-side solution, but the relationship between the client and PHP will remain the same.

In fact, this comparison with other client-side options shows the RevWeb plugin in a favorable light:
http://revmedia.runrev.com/beginners-gu ... e-compare/

If you enjoy RevTalk enough to want to use it on both the client and the server, on-rev is not your only option. While the pricing for the on-rev service is a fair bargain, the underlying technology is only incrementally more powerful than what you can enjoy by using the Rev runtime engine as a standalone (real-time debugging notwithstanding).

And in the near future, a version of the Rev engine used at on-rev.com will be available for free use on any server. You still won't have real-time debugging or a couple of other extra features specific to the on-rev hosting configuration, but it will be a pretty nice engine, in many ways rivaling the power of PHP but with the grace of chunk expressions and other RevTalk language features.

Even just using the current runtime engine as a CGI performs remarkably well, costs nothing, and on most servers takes only a couple minutes to install and test. Once in place, it's simple to write scripts for it, and with the RevWeb plugin provides a way to use one language on both the client and the server right now at zero cost.

To use your example, you could put this in your Revlet:

Code: Select all

on exportRoutine
  get the text of fld "testing2"
  put urlEncode(it) into tMyVar
  get url ("http://domain.com/cgi-bin/mythang.cgi?"& tMyVar)
  if word 1 of it is "OK" then
    answer "Data send successfully."
  else
    answer "An error occurred: "& it
  end if
end exportRoutine

And use this in your CGI script:

Code: Select all

#!../../bin/rev -ui
-- use path appropriate to your server setup

on startup
  -- Store incoming data into file:
  put $QUERY_STRING into url "file:myfile.php"
  -- Return "OK" with proper headers:
  put "Content-Type: text/html" & cr &\
      "Content-Length: 2"&cr&cr &\
      "OK" &cr&cr
end startup

One language, two minutes to set up, zero cost.

[Philhold]

Hi Richard,

Very interesting.

Would you allow a user to put an un-validated query string directly into a .php file?

In fact why store the string in a .php file at all if you are going to use it in RunRev at both ends?

Best wishes

Phil

[reelstuff]

Thank you for that analysis, as usual you think outside the box, very nice,

[mwieder]

Coming back to this discussion now, and having read through all that (whew), I'm wondering if maybe setting up a web service on the server and then communicating with it via the revlet might not be a solution for you.

[FourthWorld]

Hi Richard,

Very interesting.

Would you allow a user to put an un-validated query string directly into a .php file?

Probably not in the real world, at least not for myself or my clients. I understand that everything -- even the Pentagon -- is hackable, but I do try to make it at least a challenge.

A while back I outlined a seven-point security strategy for CGIs for one of my clients. The notes are buried in my hard drive and not all that interesting, but one of those points was requiring admin login, and another was encrypting all data in transit using keys known only to the custom client and the server.

True, neither of those are bullet-proof (in fact, any login is just a small security enhancement unless you use a secured socket, but it's no less secure than common FTP, FWIW). But they help, and reduce the pool of potential hackers down to just the most dedicated subset, a subset who may just as well have the skills to find other holes anyway.

And as for PHP, I don't use it much anymore at all ever since I figured out how to add mod_rewrite directives to my .htaccess to automatically pass Rev-embedded templates to a generic Rev CGI. What can I say, I'm a RevTalk geek. The blog at revJournal.com does this, using just the standard Rev 3.5 runtime engine as a CGI:
http://www.revjournal.com/blog.irv

I have two CGIs there, one for posting which is used only by my custom Rev client stack, and another triggered by mod_rewrite to handle any request for a file ending in ".irv". The index metadata (topic names, time stamps. etc.) are stored in one stack file for quick access as a small file (blogs don't require much data), with another stack file holding the actual posts which are retrieved only from two of the functions the blog CGI supports (the others being list views which only need to access the metadata stack). All RevTalk, top to bottom.

Probably not the most secure system, and certainly more work than using Dreamhost's one-click WordPress install. But it was a fun exercise, and now I have total control over how the blog works, able to add anything I need for that and other sites whenever I needed it in a simple code base that's fun to work on.

True enough, even with automated handling of template pages the current Rev engine is no match for the flexibility of PHP. But for a surprising variety of tasks I've found it quite satisfying.

[mwieder]

The notes are buried in my hard drive and not all that interesting

Not sure about that. If you can find the notes, that seven-point plan sounds very much apropos this topic, so if you wouldn't mind digging and posting it, I think that would be quite helpful.