Yup. You can
a) either set "jspwiki.security=off" (turning off the entire security)
b) replace AuthorizationManager with your own implementation by setting
<mapping>
<requestedClass>com.ecyrd.jspwiki.auth.AuthorizationManager</
requestedClass>
<mappedClass>com.mycompany.mypackage.MyAuthorizationManager</
mappedClass>
</mapping>
in your ini/classmappings.xml.
The latter is a largely undocumented feature, which was introduced in
2.6. It can be used to break JSPWiki very efficiently :-)
the ini/classmappings.xml can be anywhere in your classpath, just as
long as it is before JSPWiki.jar (which ships with the default
implementation). Check out the built-in classmappings.xml for more
information.
Note that MyAuthorizationManager needs to either extend (if the
original file is a class) or implement (if the original is an
interface). There are no real checks as to the integrity of the class.
I have some ideas on how to make this integration process easier, but
haven't gotten around to experimenting with them yet.
/Janne
On Jan 4, 2008, at 08:21 , Ethan Larson wrote:
Ok, I created a dummy page provider and a dummy authorizer and I
got a lot farther. I don't even need a MemoryPageProvider since I
all I need is the output (thanks just the same Florian - it was
instructive). I actually got translated output. The problem is
that I had to modify the source code to do it. I had to comment
out line 532 of WikiEngine:
//m_authorizationManager.initialize( this, props );
As near as I can tell, there's no way to create an authorization
manager that doesn't involve a jspwiki.policy under WEB-INF.
However, since I'm running it as a standalone app, I don't have a
web container and therefore no WEB-INF. I could create this under
the working directory, but I really don't want to put blank, unused
metadata in my app. Is there any way to configure this such that I
can start the authorization manager without a jspwiki.policy?
On a broader note, I'd be over the moon if this were an easier
process. JSPWiki seems to be the most actively developed and
feature-rich Java wiki there is, and has support for plugins and
filters which I will eventually need. If there were an easy way to
run the wiki translation, complete with plugins and filters, that
didn't involve a web container and any extra memory/disk usage, it
could broaden the usage quite a bit. I've looked at other java
wiki translators out there, and none of them are doing a good job
of the features/active development/ease of standalone combo
(Radeox, Bliki, VQWiki to name a few). Other forum/mailing list
posts confirm there is a demand.
Thanks for all your help,
Ethan
P.S. -- Here's my current code for anyone reading this in the future:
Properties props = new Properties();
props.setProperty(PageManager.PROP_PAGEPROVIDER,
MyPageProvider.class.getName());
props.setProperty(AuthorizationManager.PROP_AUTHORIZER,
MyAuthorizer.class.getName());
WikiEngine engine = new WikiEngine(props);
WikiContext context = new WikiContext(engine, new WikiPage(engine,
"test"));
System.out.println("output: \n" + engine.textToHTML(context, "this
is a test\n\n* more stuff"));
MyPageProvider and MyAuthorizer are both empty implentations of the
interfaces. Just return an empty List for MyPageProvider.getAllPages.
Janne Jalkanen wrote:
Yup, the problem is that there needs to be *some* kind of a page
provider, because the system needs to check if e.g. a page exists
or not when it encounters a link. The generated HTML differs in
each case.
A dummy provider will do just fine, e.g. the MemoryPageProvider.
/Janne
On Jan 2, 2008, at 00:23 , Florian Holeczek wrote:
Hi Ethan,
maybe this can help you:
http://www.jspwiki.org/wiki/MemoryPageProvider
Regards,
Florian
The problem with the page directory is that I don't want one. I
will
be managing the input/output of the text myself. I really just want
to give some wiki markup to the parser and get back html. Is there
currently a way to do this?
