[jira] [Updated] (JSPWIKI-205) Obfuscate on disk content type

["David Vittor (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JSPWIKI-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Vittor updated JSPWIKI-205:
---------------------------------
    Attachment: encryption.patch

I've created a patch that will solve this problem also.
It creates a CryptoProvider interface to the wiki for encrypting and decrypting page content.

However I'm stuck on a design decision. Should this be a filter, or a page provider? A filter is specifically for text on the page. A page provider can do both text on the page, and other things like page properties etc.

However the downside of a provider, is that it's tied to the underlying class, e.g. FileSystemProvider, VersioningFileProvider, JDBCProvider, etc. Whereas a filter is just an injection.

I'm also wondering how much of this code should be in the raw product, and how much should be just as additional plugins.

I'm thinking maybe the core jspwiki should just provide cryptography services/provider, and then custom plugins can do the actual encryption.

As always, would love to hear your thoughts.


> Obfuscate on disk content type
> ------------------------------
>
>                 Key: JSPWIKI-205
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-205
>             Project: JSPWiki
>          Issue Type: Improvement
>          Components: Core & storage
>            Reporter: Chris Lialios
>            Priority: Trivial
>         Attachments: BasicOverview.doc, EncryptingProviderSource.zip, encryption.patch
>
>
> We would like to store passwords within the wiki pages. 
> Securing the page is trivial, however the contents on disk remain clear text.
> It would be very nice to have a page type that could be stored in an obfuscated form on disk. 
> As an addition  have a secondary password to display/edit the encrypted contents on disk for those who do not want to use wiki security on the page.
> I suspect this will have potentially drastic effects on the revisions process, but it would be a small price to pay for security.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)