[jira] [Commented] (JSPWIKI-856) Enhance FileSystemProvider to be able to save page attributes as properties
[ https://issues.apache.org/jira/browse/JSPWIKI-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137548#comment-14137548 ] Harry Metske commented on JSPWIKI-856: -- Looks good to me, so +1 on this patch, anyone else opinions ? I would also like to see something in ini/jspwiki.properties describing the 3 new props: public static final String PROP_CUSTOMPROP_MAXLIMIT = custom.property.max.allowed; public static final String PROP_CUSTOMPROP_MAXKEYLENGTH = custom.property.key.length; public static final String PROP_CUSTOMPROP_MAXVALLENGTH = custom.property.value.length; Having said that, maybe it would be less confusing to rename these properties to pageproperties : public static final String PROP_CUSTOMPROP_MAXLIMIT = custom.pageproperty.max.allowed; public static final String PROP_CUSTOMPROP_MAXKEYLENGTH = custom.pageproperty.key.length; public static final String PROP_CUSTOMPROP_MAXVALLENGTH = custom.pageproperty.value.length; WDYT ? Enhance FileSystemProvider to be able to save page attributes as properties --- Key: JSPWIKI-856 URL: https://issues.apache.org/jira/browse/JSPWIKI-856 Project: JSPWiki Issue Type: New Feature Components: Core storage Affects Versions: 2.10.1 Reporter: David Vittor Priority: Minor Labels: provider Attachments: AbstractFileProvider.java, AbstractFileProvider.java, FileSystemProvider.java, FileSystemProvider.java, VersioningFileProvider.java, VersioningFileProvider.java, WikiPage.java, providers.patch, providers.patch, providers.patch *Requirements:* * 1. Plugins and other code should be able to store some page attributes into the properties of a page, just as author and changenote currently are. * 2. This should work for both FileSystemProvider and VersioningFileProvider and any future JDBCProviders or EncryptionProviders * 3. The properties added should be dynamic, e.g. all properties starting with @ like @likes, or @hitcount ** 3.1. A protected addCustomProperties() method should be done added * 4. The property names and property values should be validated ** 4.1. A protected validateCustomProperties() method should be done added ** 4.2 e.g. only contain ascii characters ** 4.3 Max property key length ** 4.4 Max property value length ** 4.5 Max number of properties -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JSPWIKI-205) Obfuscate on disk content type
[ 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)
[jira] [Commented] (JSPWIKI-205) Obfuscate on disk content type
[ https://issues.apache.org/jira/browse/JSPWIKI-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14138431#comment-14138431 ] Craig L Russell commented on JSPWIKI-205: - I'm no expert on this subject, but it seems from an architecture perspective that a filter is the better solution. I don't know of many cases where the markup for a page should be encrypted. So I'd rather see a more general purpose filter that encrypts the variable content even at the risk of exposing the fixed content with no encryption. As to the packaging, I'm a fan of providing the interface and a no-encryption filter in core that can be substituted by an encrypting filter. I seem to recall that providing an encrypting filter would require some registration for export controls. 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)
[jira] [Commented] (JSPWIKI-205) Obfuscate on disk content type
[ https://issues.apache.org/jira/browse/JSPWIKI-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14138501#comment-14138501 ] David Vittor commented on JSPWIKI-205: -- Hi Craig, Thanks for the comment. My thinking is also towards the filter, especially as being part of the core application. Custom PageProviders can always be written for specific use cases. I really like your idea of having a no-encryption as a default, which can be substituted by another one. I'll add this. Export controls?? - I didn't realize there was a way to export the wiki content? That was going to be my next task to build an export mechanism for getting the raw text pages, in a zip format, so it can be imported into a different wiki. 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)
