Re: HTML5 teaser

[Lyn Teyla]

Colin Holgate wrote:

> I may have missed a reply too. Which one covered the question of the PDF 
> remaining encrypted after the user has downloaded it?


You added the following 5 requirements after my response containing the 
suggested implementation:

1. The PDF file itself is also to be encrypted with a password.

2. The PDF encryption is not to be performed beforehand using Acrobat.

3. The PDF encryption is to be performed on the server.

4. The PDF file is to remain encrypted upon receipt.

5. The user is to be prompted to enter the password to unlock it.


With your above additional requirements in mind, the suggested implementation 
would be as follows:

- Store the PDF on the server, somewhere outside the web folder so it can’t be 
loaded directly by web visitors.

- Get the user to access the system via a HTTPS connection, which is needed for 
a secure login mechanism anyway.

- The HTTPS connection does all of the encrypting and decrypting so you don’t 
have to code it yourself.

- The user logs in via your LiveCode Server app, which handles the usual user 
authentication stuff using cookies and sessions.

- When the logged in user asks for the PDF file, have your LiveCode Server app 
generate a new password and send it to a command line app that has the ability 
to encrypt PDF files, such as PDFtk:

https://www.pdflabs.com/docs/pdftk-man-page/

- Have that command line app output the encrypted PDF file to a location 
outside the web folder so it can’t be loaded directly by web visitors.

- Have your LiveCode Server app display the newly-generated password on a page 
in the web browser, with an accompanying download link which calls your 
LiveCode Server app.

- When the user clicks the download link, have your LiveCode Server app read 
from the encrypted PDF file and write it out to the web browser (as with any 
other web content), and with the appropriate Content-Type HTTP header.

- Since you’re having all data transmitted over a HTTPS connection, the user’s 
login details as well as the PDF file are encrypted whilst in transit.

- Since your LiveCode Server app is the one deciding whether or not to display 
the PDF (and any other data) based on whether the user is signed in, access can 
be effectively limited to that user.


Lyn




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Mark Wieder]

On 03/05/2016 01:46 PM, Colin Holgate wrote:

I may have missed a reply too. Which one covered the question of the PDF 
remaining encrypted after the user has downloaded it?


Sorry, I cleaned out my mailboxes earlier. Look for Lyn's longer reply 
about three levels back in this discussion.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Lyn Teyla]

Mark Wieder wrote:

> On 03/04/2016 06:38 PM, Lyn Teyla wrote:
> 
>> Using a HTTPS connection ensures that the PDF file is transmitted securely.
> 
> Uh, sorry, no.
> HTTPS by itself will (mostly) guarantee that you are connected to the server 
> you think you're connecting to. There's no encryption unless you enforce it 
> yourself. The connection itself isn't in cleartext after the initial 
> handshake, so someone listening in on the network traffic won't be able to 
> grab and view the pdf, but unless you're requiring a login and encrypting the 
> file, there's nothing to stop anyone from going to the https url and picking 
> up a copy of the file.


The whole point of HTTPS is _not_ just to authenticate the website, but also to 
encrypt the data in transit:

https://en.wikipedia.org/wiki/HTTPS

That’s precisely why online banking and ecommerce websites use HTTPS — to 
encrypt credit card and other important data during transmission. The same 
would apply to the PDF file being transmitted via HTTPS.

The OP’s question being answered here was "Does the PDF _travel_ securely?" and 
not "Can anyone go to the HTTPS URL and pick up a copy of the file?". My 
statement was in response to that specific question, which was clearly quoted 
immediate prior to the statement itself.

The latter question had already been addressed in my earlier reply, in which I 
described placing the PDF file outside the web folder on the server, as well as 
a user login mechanism being utilized, per the OP’s initial requirements.

Lyn



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[[-hh]]

Just as an idea:
A few times I used this one (it's basically AES-128).
There are also examples that basically worked for me.

So: Not really an experience but the few times it worked.
https://github.com/defuse/php-encryption

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Colin Holgate]

I think we weren’t planning on using Acrobat at all. It would be an unencrypted 
PDF that is encrypted on a server, saved locally with the same encryption, and 
only viewable by the logged in user as a local file,


> On Mar 4, 2016, at 10:55 PM, stephen barncard 
>  wrote:
> 
> On Fri, Mar 4, 2016 at 7:23 PM, Colin Holgate 
> wrote:
> 
>> I found out more info, the local copy of the PDF needs to be encrypted
>> too. This isn’t what it is, but imagine it’s top-secret, that even other
>> users of your computer shouldn’t see, I need to download the file and just
>> let you see it, with some sort of password entry to unlock it.
>> 
> then you can't use Adobe Acrobat to do the encryption before placing on the
> server ?  Then Adobe Reader can handle the decryption and password
> 
> what am I missing ?
> 
> Stephen Barncard - Sebastopol Ca. USA -
> mixstream.org
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Mark Wieder]

On 03/04/2016 06:38 PM, Lyn Teyla wrote:


Using a HTTPS connection ensures that the PDF file is transmitted securely.


Uh, sorry, no.
HTTPS by itself will (mostly) guarantee that you are connected to the 
server you think you're connecting to. There's no encryption unless you 
enforce it yourself. The connection itself isn't in cleartext after the 
initial handshake, so someone listening in on the network traffic won't 
be able to grab and view the pdf, but unless you're requiring a login 
and encrypting the file, there's nothing to stop anyone from going to 
the https url and picking up a copy of the file.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[stephen barncard]

On Fri, Mar 4, 2016 at 7:23 PM, Colin Holgate 
wrote:

> I found out more info, the local copy of the PDF needs to be encrypted
> too. This isn’t what it is, but imagine it’s top-secret, that even other
> users of your computer shouldn’t see, I need to download the file and just
> let you see it, with some sort of password entry to unlock it.
>
then you can't use Adobe Acrobat to do the encryption before placing on the
server ?  Then Adobe Reader can handle the decryption and password

what am I missing ?

Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Colin Holgate]

I found out more info, the local copy of the PDF needs to be encrypted too. 
This isn’t what it is, but imagine it’s top-secret, that even other users of 
your computer shouldn’t see, I need to download the file and just let you see 
it, with some sort of password entry to unlock it.


> On Mar 4, 2016, at 10:18 PM, [-hh]  wrote:
> 
>> Colin H. wrote:
>> A PDF is online somewhere...
> 
> Of course, if you don't insist on HTML5 (despite the subject)
> you could also think about simpler solutions available in php
> which is much faster than LC server.
> Others here (Peter H.?) will have several ready made solutions
> for that.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[[-hh]]

> Colin H. wrote:
> A PDF is online somewhere...

Of course, if you don't insist on HTML5 (despite the subject)
you could also think about simpler solutions available in php
which is much faster than LC server.
Others here (Peter H.?) will have several ready made solutions
for that.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Lyn Teyla]

Colin Holgate wrote:

> Is LiveCode required in what you say?

You can use LiveCode Server (or any other server-side language) to perform 
those tasks.

> Does the PDF travel securely?

Using a HTTPS connection ensures that the PDF file is transmitted securely.

Lyn



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Colin Holgate]

Thanks for the detailed explanation.

Is LiveCode required in what you say?

Does the PDF travel securely?


> On Mar 4, 2016, at 7:57 PM, Lyn Teyla  wrote:
> 
> Colin Holgate wrote:
> 
>> A PDF is online somewhere. A logged in user asks for it, and the server 
>> encrypts it before sending over, using some sort of key that was in the 
>> query. On receiving the data, the client side would have to unencrypted it, 
>> and show it as the original PDF in a browser.
> 
> This only involves LiveCode Server and doesn’t require LiveCode HTML5, 
> JavaScript, sending any keys in the query, or writing any PDF files to the 
> user’s hard drive.
> 
> Here’s a general outline of the implementation:
> 
> - Store the PDF on the server, somewhere outside the web folder so it can’t 
> be loaded directly by web visitors.
> 
> - Get the user to access the system via a HTTPS connection, which is needed 
> for a secure login mechanism anyway.
> 
> - The HTTPS connection does all of the encrypting and decrypting so you don’t 
> have to code it yourself.
> 
> - The user logs in via your LiveCode Server app, which handles the usual user 
> authentication stuff using cookies and sessions.
> 
> - When the logged in user asks for the PDF file, have your LiveCode Server 
> app read from the PDF file and write it out to the web browser (as with any 
> other web content), and with the appropriate Content-Type HTTP header.
> 
> - Since you’re having all data transmitted over a HTTPS connection, the 
> user’s login details as well as the PDF file are encrypted whilst in transit.
> 
> - Since your LiveCode Server app is the one deciding whether or not to 
> display the PDF (and any other data) based on whether the user is signed in, 
> access can be effectively limited to that user.
> 
> Lyn
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Lyn Teyla]

Colin Holgate wrote:

> A PDF is online somewhere. A logged in user asks for it, and the server 
> encrypts it before sending over, using some sort of key that was in the 
> query. On receiving the data, the client side would have to unencrypted it, 
> and show it as the original PDF in a browser.

This only involves LiveCode Server and doesn’t require LiveCode HTML5, 
JavaScript, sending any keys in the query, or writing any PDF files to the 
user’s hard drive.

Here’s a general outline of the implementation:

- Store the PDF on the server, somewhere outside the web folder so it can’t be 
loaded directly by web visitors.

- Get the user to access the system via a HTTPS connection, which is needed for 
a secure login mechanism anyway.

- The HTTPS connection does all of the encrypting and decrypting so you don’t 
have to code it yourself.

- The user logs in via your LiveCode Server app, which handles the usual user 
authentication stuff using cookies and sessions.

- When the logged in user asks for the PDF file, have your LiveCode Server app 
read from the PDF file and write it out to the web browser (as with any other 
web content), and with the appropriate Content-Type HTTP header.

- Since you’re having all data transmitted over a HTTPS connection, the user’s 
login details as well as the PDF file are encrypted whilst in transit.

- Since your LiveCode Server app is the one deciding whether or not to display 
the PDF (and any other data) based on whether the user is signed in, access can 
be effectively limited to that user.

Lyn



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[[-hh]]

Forgot to add the link where you can try which functions work (or not) in dp-15 
HTML5 standalones:

Because on-rev is moving tonight, you could use this one:
http://hyperhh.org/html5/TerminalZero-8.0.0-dp-15X.html
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Colin Holgate]

Hopefully the exception key would help. Only the user would know how to 
unencrypt the image.


> On Mar 4, 2016, at 7:07 PM, [-hh]  wrote:
> 
> Currently the ask dialog is the **only** way to communicate
> with a HTML5 standalone.
> You simply have to manage, that your imagedata can pass the
> dialog (no CR). And be aware that everybody can read your
> script, but that shouldn't matter. The rest works "as usual".
> The copy/paste via "ask" mechanism works (there are examples
> to try).
> 
>> Colin H. wrote:
>> I’ve been tasked with a problem to solve, and I think I can 
>> use any tool to do it. LiveCode could be a good choice. 
>> Here’s what’s needed:
>> A PDF is online somewhere. A logged in user asks for it, 
>> and the server encrypts it before sending over, using some 
>> sort of key that was in the query. On receiving the data, 
>> the client side would have to unencrypted it, and show it 
>> as the original PDF in a browser.
>> I feel sure there are some difficulties in there, such as
>> whether Javascript can write a file to the user’s hard 
>> drive, and then show it in a browser. In LiveCode terms, 
>> one solution would be to send it as encrypted image data, 
>> and then set the imagedata of an image to the unencrypted 
>> version (if setting imagedata is allowed in the HTML5 
>> export from LiveCode).
> 
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[[-hh]]

Currently the ask dialog is the **only** way to communicate
with a HTML5 standalone.
You simply have to manage, that your imagedata can pass the
dialog (no CR). And be aware that everybody can read your
script, but that shouldn't matter. The rest works "as usual".
The copy/paste via "ask" mechanism works (there are examples
to try).

> Colin H. wrote:
> I’ve been tasked with a problem to solve, and I think I can 
> use any tool to do it. LiveCode could be a good choice. 
> Here’s what’s needed:
> A PDF is online somewhere. A logged in user asks for it, 
> and the server encrypts it before sending over, using some 
> sort of key that was in the query. On receiving the data, 
> the client side would have to unencrypted it, and show it 
> as the original PDF in a browser.
> I feel sure there are some difficulties in there, such as
> whether Javascript can write a file to the user’s hard 
> drive, and then show it in a browser. In LiveCode terms, 
> one solution would be to send it as encrypted image data, 
> and then set the imagedata of an image to the unencrypted 
> version (if setting imagedata is allowed in the HTML5 
> export from LiveCode).




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Colin Holgate]

Yes. There are other options, but I was hoping that LiveCode could do it in an 
easier way. At worse, the encryption could be as simple as Base64.


> On Mar 4, 2016, at 6:48 PM, Monte Goulding  wrote:
> 
> I wouldn't expect imageData to be an issue in HTML5 but encryption seems like 
> a stretch at this stage. Does it need to be in a browser?
> 
> Sent from my iPhone
> 
>> On 5 Mar 2016, at 8:35 AM, Colin Holgate  wrote:
>> 
>> I’ve been tasked with a problem to solve, and I think I can use any tool to 
>> do it. LiveCode could be a good choice. Here’s what’s needed:
>> 
>> A PDF is online somewhere. A logged in user asks for it, and the server 
>> encrypts it before sending over, using some sort of key that was in the 
>> query. On receiving the data, the client side would have to unencrypted it, 
>> and show it as the original PDF in a browser.
>> 
>> I feel sure there are some difficulties in there, such as whether Javascript 
>> can write a file to the user’s hard drive, and then show it in a browser. In 
>> LiveCode terms, one solution would be to send it as encrypted image data, 
>> and then set the imagedata of an image to the unencrypted version (if 
>> setting imagedata is allowed in the HTML5 export from LiveCode).
>> 
>> Do you all see other difficulties, or maybe simple solutions to the problem? 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML5 teaser

[Monte Goulding]

I wouldn't expect imageData to be an issue in HTML5 but encryption seems like a 
stretch at this stage. Does it need to be in a browser?

Sent from my iPhone

> On 5 Mar 2016, at 8:35 AM, Colin Holgate  wrote:
> 
> I’ve been tasked with a problem to solve, and I think I can use any tool to 
> do it. LiveCode could be a good choice. Here’s what’s needed:
> 
> A PDF is online somewhere. A logged in user asks for it, and the server 
> encrypts it before sending over, using some sort of key that was in the 
> query. On receiving the data, the client side would have to unencrypted it, 
> and show it as the original PDF in a browser.
> 
> I feel sure there are some difficulties in there, such as whether Javascript 
> can write a file to the user’s hard drive, and then show it in a browser. In 
> LiveCode terms, one solution would be to send it as encrypted image data, and 
> then set the imagedata of an image to the unencrypted version (if setting 
> imagedata is allowed in the HTML5 export from LiveCode).
> 
> Do you all see other difficulties, or maybe simple solutions to the problem? 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

HTML5 teaser

[Colin Holgate]

I’ve been tasked with a problem to solve, and I think I can use any tool to do 
it. LiveCode could be a good choice. Here’s what’s needed:

A PDF is online somewhere. A logged in user asks for it, and the server 
encrypts it before sending over, using some sort of key that was in the query. 
On receiving the data, the client side would have to unencrypted it, and show 
it as the original PDF in a browser.

I feel sure there are some difficulties in there, such as whether Javascript 
can write a file to the user’s hard drive, and then show it in a browser. In 
LiveCode terms, one solution would be to send it as encrypted image data, and 
then set the imagedata of an image to the unencrypted version (if setting 
imagedata is allowed in the HTML5 export from LiveCode).

Do you all see other difficulties, or maybe simple solutions to the problem? 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode