[
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)
