Got it, thanks Foster. Foster Schucker wrote: > There is a line in the property file that sets it. Look around line > 300 or so... > > Ours looks like this: > > jspwiki.translatorReader.inlinePattern.1 = *.jpg > jspwiki.translatorReader.inlinePattern.2 = *.JPG > jspwiki.translatorReader.inlinePattern.3 = *.gif > jspwiki.translatorReader.inlinePattern.4 = *.GIF > jspwiki.translatorReader.inlinePattern.5 = *.png > jspwiki.translatorReader.inlinePattern.6 = *.PNG > > Lana Frost wrote: > >> Hi, >> >> Our wiki currently supports .png format only for inlined images. I >> can't find where we set this variable so that we can upload .gif as >> well. >> >> Thanks for your help, >> Lana >> >> >> >
There is a line in the property file that sets it. Look around line 300 or so... Ours looks like this: jspwiki.translatorReader.inlinePattern.1 = *.jpg jspwiki.translatorReader.inlinePattern.2 = *.JPG jspwiki.translatorReader.inlinePattern.3 = *.gif jspwiki.translatorReader.inlinePattern.4 = *.GIF jspwiki.translatorReader.inlinePattern.5 = *.png jspwiki.translatorReader.inlinePattern.6 = *.PNG Lana Frost wrote: > Hi, > > Our wiki currently supports .png format only for inlined images. I > can't find where we set this variable so that we can upload .gif as well. > > Thanks for your help, > Lana > > >
Hi, Our wiki currently supports .png format only for inlined images. I can't find where we set this variable so that we can upload .gif as well. Thanks for your help, Lana
Yes, they should be. Again, since Lucene has its own update queue, which is not run immediately, it may take a few seconds for the results to update. /Janne On Dec 6, 2009, at 23:19 , Maduranga Kannangara wrote: > When you do changes to a certain page, directly from file system, > does the Lucene indexes get updated? > i.e.: Does search results change, reflecting new changes? > > Thanks > Madu > > -----Original Message----- > From: Frank.Fitch@Sun.COM [mailto:Frank.Fitch@Sun.COM] > Sent: Saturday, 5 December 2009 4:02 AM > To: jspwiki-user@incubator.apache.org > Subject: Re: Can you update a JSPWiki page from outside the JSPWiki > application? > > Carlson, Eric R wrote: >> Is it possible to update a page within JSPWiki from an application >> outside of JSPWiki and have the new, modified page show up for >> JSPWiki users? > > Yes. I do it all the time. > > Just create the page content with the wiki source syntax (or good > old html if your wiki has html enabled). Copy the page into the > wiki content dir. > > You can modify an existing page or create new pages this way. If you > create a new page, be sure the file name starts with an upper > case letter and ends with ".txt". this is required because of a flaw > in the wiki. > > The wiki recognizes the changes immediately. > > You may want to make it clear in the source code comments and the > page content that the page is automatically generated from an > external source. Your colleagues may become annoyed if their changes > disappear. :) > > Regards, > -Frank
When you do changes to a certain page, directly from file system, does the Lucene indexes get updated? i.e.: Does search results change, reflecting new changes? Thanks Madu -----Original Message----- From: Frank.Fitch@Sun.COM [mailto:Frank.Fitch@Sun.COM] Sent: Saturday, 5 December 2009 4:02 AM To: jspwiki-user@incubator.apache.org Subject: Re: Can you update a JSPWiki page from outside the JSPWiki application? Carlson, Eric R wrote: > Is it possible to update a page within JSPWiki from an application outside of JSPWiki and have the new, modified page show up for > JSPWiki users? Yes. I do it all the time. Just create the page content with the wiki source syntax (or good old html if your wiki has html enabled). Copy the page into the wiki content dir. You can modify an existing page or create new pages this way. If you create a new page, be sure the file name starts with an upper case letter and ends with ".txt". this is required because of a flaw in the wiki. The wiki recognizes the changes immediately. You may want to make it clear in the source code comments and the page content that the page is automatically generated from an external source. Your colleagues may become annoyed if their changes disappear. :) Regards, -Frank
WikPageStatPlugin gets all his information from PageManager and AttachmentManager, and is not very usefull for the type of statistics you are looking for. But I'd be happy to share the code. A user list is already available in the SessionsPlugin. Information about user edits is not stored anywhere now, but this could be an enhancement (please file a JIRA issue at https://issues.apache.org/jira/browse/JSPWIKI ) regards, Harry 2009/12/5 lgilardoni61@gmail.com <lgilardoni61@gmail.com> > Harry > > > Harry Metske wrote: > >> LG, >> >> not quite sure what kind of stats you are looking for, but I wrote a >> plugin >> a few months ago that gathers page statistics, including a summary. >> Here you can see an example just to give you an idea : >> http://www.computerhok.nl/JSPWiki/Wiki.jsp?page=TestWikiPageStatPlugin >> >> >> > mor or less ... I'm more interested in statistics biased towards users > (e.g. user list, number of edits etc more than page list) > but the data is there. > > It sure is not production ready, I would not run it on a very large wiki >> (although it caches results). >> >> > I would be happy to give it a try - and possibly work on it if needed. Is > it already shared? > > Luca > > last ... 3.0? I'm still on 2.8 > > regards, >> Harry >> >> 2009/12/4 lgilardoni61@gmail.com <lgilardoni61@gmail.com> >> >> >> >>> Hi, is it possible (i.e. anthing already done) to get statistics about >>> usage (page changed) by users? >>> The info is there (from the page info one can see the whole history of >>> changes) but is there any plugin/code snippet already available or to >>> start >>> from? >>> >>> Tx in advance >>> >>> LG >>> >>> >>> >> >> >> > >
Harry Harry Metske wrote: > LG, > > not quite sure what kind of stats you are looking for, but I wrote a plugin > a few months ago that gathers page statistics, including a summary. > Here you can see an example just to give you an idea : > http://www.computerhok.nl/JSPWiki/Wiki.jsp?page=TestWikiPageStatPlugin > > mor or less ... I'm more interested in statistics biased towards users (e.g. user list, number of edits etc more than page list) but the data is there. > It sure is not production ready, I would not run it on a very large wiki > (although it caches results). > I would be happy to give it a try - and possibly work on it if needed. Is it already shared? Luca last ... 3.0? I'm still on 2.8 > regards, > Harry > > 2009/12/4 lgilardoni61@gmail.com <lgilardoni61@gmail.com> > > >> Hi, is it possible (i.e. anthing already done) to get statistics about >> usage (page changed) by users? >> The info is there (from the page info one can see the whole history of >> changes) but is there any plugin/code snippet already available or to start >> from? >> >> Tx in advance >> >> LG >> >> > >
> The wiki recognizes the changes immediately. To be specific, if you are using CachingProvider, it should happen within 30 seconds. Note that the repository format will change in 3.0. /Janne
did you place robots.txt in the root of the web site hierarchy ? Meaning the url for the robots.txt must be something like http://mywonderfulsite.somewhere.org/robots.txt, and not ttp:// mywonderfulsite.somewhere.org/JSPWiki/robots.txt Did you look at you access.log to see if robots.txt is asked for ? /Harry 2009/12/5 Robert FORBES <rforbes@highlinecorp.com> > I don't want Google to index my pages, but I cannot find any means to block > it. As a last ditch effort, I have put the JSPWiki installation behind a > firewall, but this is defeating the purpose for which it is intended. > > I am using Tomcat right now as the app server, and I have a robots.txt file > in the WebApps folder, the folder below that (where Wiki.jsp is), the > WEB_INF folder, and anywhere else I can think of. The robots file looks > like this: > > User-agent: * > Disallow: / > > But it is not working. Am I missing something obvious ? (likely) > > Robert > >
I don't want Google to index my pages, but I cannot find any means to block it. As a last ditch effort, I have put the JSPWiki installation behind a firewall, but this is defeating the purpose for which it is intended. I am using Tomcat right now as the app server, and I have a robots.txt file in the WebApps folder, the folder below that (where Wiki.jsp is), the WEB_INF folder, and anywhere else I can think of. The robots file looks like this: User-agent: * Disallow: / But it is not working. Am I missing something obvious ? (likely) Robert
LG, not quite sure what kind of stats you are looking for, but I wrote a plugin a few months ago that gathers page statistics, including a summary. Here you can see an example just to give you an idea : http://www.computerhok.nl/JSPWiki/Wiki.jsp?page=TestWikiPageStatPlugin It sure is not production ready, I would not run it on a very large wiki (although it caches results). regards, Harry 2009/12/4 lgilardoni61@gmail.com <lgilardoni61@gmail.com> > Hi, is it possible (i.e. anthing already done) to get statistics about > usage (page changed) by users? > The info is there (from the page info one can see the whole history of > changes) but is there any plugin/code snippet already available or to start > from? > > Tx in advance > > LG >
Hi, is it possible (i.e. anthing already done) to get statistics about usage (page changed) by users? The info is there (from the page info one can see the whole history of changes) but is there any plugin/code snippet already available or to start from? Tx in advance LG
Carlson, Eric R wrote: > Is it possible to update a page within JSPWiki from an application outside of JSPWiki and have the new, modified page show up for > JSPWiki users? Yes. I do it all the time. Just create the page content with the wiki source syntax (or good old html if your wiki has html enabled). Copy the page into the wiki content dir. You can modify an existing page or create new pages this way. If you create a new page, be sure the file name starts with an upper case letter and ends with ".txt". this is required because of a flaw in the wiki. The wiki recognizes the changes immediately. You may want to make it clear in the source code comments and the page content that the page is automatically generated from an external source. Your colleagues may become annoyed if their changes disappear. :) Regards, -Frank
Is it possible to update a page within JSPWiki from an application outside of JSPWiki and have the new, modified page show up for JSPWiki users? What I'm doing is using JSPWiki as a framework to deliver reports to users. I have a page that essentially shows a calendar with dates that have valid reports showing up as links, and those that do not have valid reports showing up as un-clickable text. This calendar page consists of lots of inline HTML in a JSPWiki page, with links to individual JSPWiki pages for each date. Those individual 'date' pages consist of a list of links to the reports, which are external to JSPWiki. I have a routine to produce the reports on a daily basis and move them to their final destination and I would like to automate the updating of the calendar to add each new date as I create the reports, and to create a new 'date' page for the new reports. The programming to update the calendar and create the new date page are straightforward, and I don't need any help with that. I'm just wondering if JSPWiki will recognize the updated page, or if there is something I need to do to refresh it. Eric R. Carlson Eric.Carlson@kroger.com (513)-387-7739 ________________________________ This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Folks, we just rolled a new release of JSPWiki 2.8.3, available from the usual location at http://www.jspwiki.org/wiki/JSPWikiDownload/ JSPWiki 2.8.3 is a security and stability update to 2.8.x-series. All users are encouraged to upgrade. The full log of any issues fixed can be found at: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310732&fixfor=12313766 This is the first major version of JSPWiki which is released completely under the Apache License. This is done as a part of the transition to the Apache Incubation. However, this is NOT an Apache release - JSPWiki 3.0 will be the first official Apache release. Please report any issues at https://issues.apache.org/jira/browse/JSPWIKI UPDATES SINCE 2.8.2 =================== The full list is available in the ChangeLog file. Highlights include * Improved logging * JDK6 compilation support * Brazilian Portuguese translation, thanks to Paulo Amaral * Addition of new PageViewPlugin * Numerous bugfixes, esp. in sorting.
[apologies for cross-posting; please respond only to the mailing list
in which you are a member, and if both, please post to jspwiki-dev]
Hello. The developer group recently learned that JSPWiki was passed up
by Sun Microsystems' OpenSolaris community wiki due to a number of
putative failings. One of these is a lack of support for right-to-left
(RTL) text, such as Arabic, Hebrew, Punjabi, or Kashmiri. We'd like to
remedy that, but need some help, as none of our developers speak or
write an RTL language (to my knowledge).
If you or your organisation's wiki are currently using a right-to-left
script and are willing to provide us with feedback on any failings in
JSPWiki's implementation, we'd be very happy to work with you on fixing
those bugs. It would benefit the JSPWiki community as well as improving
JSPWiki's support for your language. You can help contribute to world
happiness.
If you'd prefer not to provide that help on the public mailing list,
you can also contact me directly at: murray09 at altheim dot com.
Thanks much for any help,
Murray
...........................................................................
Murray Altheim <murray09 at altheim dot com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Workaround I would use for this (Dirty way, of course..):
[{ALLOW upload Familie}]
-----Original Message-----
From: Harry Metske [mailto:harry.metske@gmail.com]
Sent: Tuesday, 27 October 2009 5:42 AM
To: jspwiki-user@incubator.apache.org
Subject: Re: ACL questions
Harald,
are you sure this is not a browser caching issue, this problem has been
reported before : https://issues.apache.org/jira/browse/JSPWIKI-361
Also, can you reproduce the problem on http://sandbox.jspwiki.org ?
regards,
Harry
2009/10/26 Harald Krammer <Harald.Krammer@hkr.at>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello,
> I am again. I played around with the permission concept e.g. [{ALLOW
> edit harald}] and following questions are unclear for me.
>
> *) When I set page permissions, attachments are not
> considered. e.g. I made a side with permissions
> [{ALLOW edit hk}] and [{ALLOW view Familie}] on side
> https://xen.hkr.at/wiki/Wiki.jsp?page=secret
> Permissions are fine, but a direct link to attachments on side secrete
> works without any restrictions.
> e.g.: https://xen.hkr.at/wiki/attach/Secret/non-public.txt
>
> Is that a limitation, a known issue, a bug or a wrong user usage?
>
> *) Exits an overview plug-in about permissions of all sides?
> Currently I do it around with a shell script. I know it's the wrong way,
> but easy for me to check permissions problems.
>
> *) Usage of if-plugin
>
> Currently I use the ifplugin, because it's easy to use. Exits a way to
> disable 'view page source' for e.g. non authenticated users?
>
>
> Nice greetings,
> Harald
>
>
> - --
>
> Harald Krammer
> Brucknerstrasse 33
> A - 4020 Linz
> AUSTRIA
>
> Mobil +43.(0) 664. 130 59 58
> Mail: Harald.Krammer (at) hkr.at
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREIAAYFAkrl60oACgkQ9QlAsubHO9tZdACg4iRRAaXN82thHPc5tClLah4b
> QIAAni+/qATdb9f66KpAaIZ7Wkh079EQ
> =J6Cn
> -----END PGP SIGNATURE-----
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello Harry,
you are right. It's a browser issue.
When I clear the cache by hand in my browser then it works as expected.
Strange... The refresh button did not work....
Here a few parts in the http-header:
If-Modified-Since: Mon, 26 Oct 2009 17:40:29 GMT
Cache-Control:max-age=0
If I can trust firebug then every refresh increases the cache expires
time!? ( I use firefox 3.0)
Nice greetings,
Harald
Harry Metske schrieb:
> Harald,
>
> are you sure this is not a browser caching issue, this problem has been
> reported before : https://issues.apache.org/jira/browse/JSPWIKI-361
>
> Also, can you reproduce the problem on http://sandbox.jspwiki.org ?
>
> regards,
> Harry
>
> 2009/10/26 Harald Krammer <Harald.Krammer@hkr.at>
>
> Hello,
> I am again. I played around with the permission concept e.g. [{ALLOW
> edit harald}] and following questions are unclear for me.
>
> *) When I set page permissions, attachments are not
> considered. e.g. I made a side with permissions
> [{ALLOW edit hk}] and [{ALLOW view Familie}] on side
> https://xen.hkr.at/wiki/Wiki.jsp?page=secret
> Permissions are fine, but a direct link to attachments on side secrete
> works without any restrictions.
> e.g.: https://xen.hkr.at/wiki/attach/Secret/non-public.txt
>
> Is that a limitation, a known issue, a bug or a wrong user usage?
>
> *) Exits an overview plug-in about permissions of all sides?
> Currently I do it around with a shell script. I know it's the wrong way,
> but easy for me to check permissions problems.
>
> *) Usage of if-plugin
>
> Currently I use the ifplugin, because it's easy to use. Exits a way to
> disable 'view page source' for e.g. non authenticated users?
>
>
> Nice greetings,
> Harald
>
>
>>
- --
Harald Krammer
Brucknerstrasse 33
A - 4020 Linz
AUSTRIA
Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREIAAYFAkrl9icACgkQ9QlAsubHO9td+ACfWrhnEvxa7YAqdRZrjZYteaKD
xOwAn1QANqIE3dy07a0f8/jpbCNgIDg1
=EY8Z
-----END PGP SIGNATURE-----
Harald,
are you sure this is not a browser caching issue, this problem has been
reported before : https://issues.apache.org/jira/browse/JSPWIKI-361
Also, can you reproduce the problem on http://sandbox.jspwiki.org ?
regards,
Harry
2009/10/26 Harald Krammer <Harald.Krammer@hkr.at>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello,
> I am again. I played around with the permission concept e.g. [{ALLOW
> edit harald}] and following questions are unclear for me.
>
> *) When I set page permissions, attachments are not
> considered. e.g. I made a side with permissions
> [{ALLOW edit hk}] and [{ALLOW view Familie}] on side
> https://xen.hkr.at/wiki/Wiki.jsp?page=secret
> Permissions are fine, but a direct link to attachments on side secrete
> works without any restrictions.
> e.g.: https://xen.hkr.at/wiki/attach/Secret/non-public.txt
>
> Is that a limitation, a known issue, a bug or a wrong user usage?
>
> *) Exits an overview plug-in about permissions of all sides?
> Currently I do it around with a shell script. I know it's the wrong way,
> but easy for me to check permissions problems.
>
> *) Usage of if-plugin
>
> Currently I use the ifplugin, because it's easy to use. Exits a way to
> disable 'view page source' for e.g. non authenticated users?
>
>
> Nice greetings,
> Harald
>
>
> - --
>
> Harald Krammer
> Brucknerstrasse 33
> A - 4020 Linz
> AUSTRIA
>
> Mobil +43.(0) 664. 130 59 58
> Mail: Harald.Krammer (at) hkr.at
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREIAAYFAkrl60oACgkQ9QlAsubHO9tZdACg4iRRAaXN82thHPc5tClLah4b
> QIAAni+/qATdb9f66KpAaIZ7Wkh079EQ
> =J6Cn
> -----END PGP SIGNATURE-----
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
I am again. I played around with the permission concept e.g. [{ALLOW
edit harald}] and following questions are unclear for me.
*) When I set page permissions, attachments are not
considered. e.g. I made a side with permissions
[{ALLOW edit hk}] and [{ALLOW view Familie}] on side
https://xen.hkr.at/wiki/Wiki.jsp?page=secret
Permissions are fine, but a direct link to attachments on side secrete
works without any restrictions.
e.g.: https://xen.hkr.at/wiki/attach/Secret/non-public.txt
Is that a limitation, a known issue, a bug or a wrong user usage?
*) Exits an overview plug-in about permissions of all sides?
Currently I do it around with a shell script. I know it's the wrong way,
but easy for me to check permissions problems.
*) Usage of if-plugin
Currently I use the ifplugin, because it's easy to use. Exits a way to
disable 'view page source' for e.g. non authenticated users?
Nice greetings,
Harald
- --
Harald Krammer
Brucknerstrasse 33
A - 4020 Linz
AUSTRIA
Mobil +43.(0) 664. 130 59 58
Mail: Harald.Krammer (at) hkr.at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREIAAYFAkrl60oACgkQ9QlAsubHO9tZdACg4iRRAaXN82thHPc5tClLah4b
QIAAni+/qATdb9f66KpAaIZ7Wkh079EQ
=J6Cn
-----END PGP SIGNATURE-----
...you check out the trunk and look at the javadocs, which are extremely well-documented. Sorry my reply came as a serialization... I did it one-handed on the iPhone and fat-fingered TWICE. Andrew On Oct 25, 2009, at 7:10, Andrew Jaquith <andrew.r.jaquith@gmail.com> wrote: > Sorry-- I fat-fingered the send button! > > Anyhow, with the LdapUserDatabase you won't need to provision or > deprovision because everything will be in LDAP. We will keep some > data locally (user prefs) but that's it. > > At this point, if you still have concerns I'd recommend yo > > On Oct 25, 2009, at 7:04, Andrew Jaquith > <andrew.r.jaquith@gmail.com> wrote: > >> I should not have used the magic word "provision" in my last post. >> The important concept is that when the LdapUserDatabase is used, >> LDAP *is* the user database >> >> On Oct 25, 2009, at 6:38, Jim Willeke <jim@willeke.com> wrote: >> >>> But what about de-provisioning users? >>> >>> The issue with putting users in yet another database in the >>> enterprise world >>> central provisioning, de-provisioning and RBAC are the strategic >>> directions >>> with no desire to mange users in remote stores. >>> >>> And why would someone want to put in information into the WIKI >>> when it is >>> already been add to the user in LDAP via the enterprise portal? >>> >>> I will agree the local "groups" concept is necessary, but it >>> should be an >>> agumnetation to container managed security that most enterprises >>> would >>> utilize. >>> >>> So users in the role (perhaps by department) "Sales" would always >>> be able to >>> view any pages with "Sales": >>> >>> Then the local "groups" would be done to perform "teaming" >>> arrangements as >>> would be done in a project that would cross departmental lines. >>> >>> -jim >>> Jim Willeke >>> >>> >>> On Sat, Oct 24, 2009 at 11:12 AM, Andrew Jaquith <andrew.r.jaquith@gmail.com >>>> wrote: >>> >>>> JSPWiki 3.0 trunk already has an LdapUserDatabase and >>>> LdapAuthorizer, >>>> which means that it can obtain user profiles on a read-only basis >>>> from >>>> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your >>>> users will be "provisioned" in JSPWiki automatically. This should >>>> solve the user-experience problem you described. >>>> >>>> The upcoming 3.0 LDAP features have been developed and tested with >>>> Active Directory and OpenLDAP. It is configured via the GUI at >>>> install-time. >>>> >>>> With respect to permissions and group memberships: these are good >>>> suggestions. We still have some work to do for the GUI for ACLs for >>>> 3.0. I agree that we should be validating user names when users >>>> create >>>> the ACLs. Same for adding users to groups. These suggestions will >>>> be >>>> incorporated into how the ACL GUIs work -- likely via AJAX in >>>> real-time. >>>> >>>> Andrew >>>> >>>> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt >>>> <te@zama.org> wrote: >>>>> The group and permission system in the jspwiki is rather >>>>> dynamic, and >>>> ldaps >>>>> tends to be readonly except for a groups of administrators. >>>>> There for >>>> there >>>>> is still need for the user.xml and group.xml. But in my opinion >>>>> the >>>> user.xml >>>>> needs to be automatically updated when a new ldap user is logged >>>>> in. >>>>> >>>>> Otherwise granting and managing jspwiki permissions i a >>>>> nightmare, this >>>> also >>>>> enhanced since there is no check on if a user exist - when >>>>> adding users >>>> to >>>>> wiki group or setting a page permission. >>>>> >>>>> I think the following should be changed. >>>>> >>>>> - First time a new user is logged in - the user should be added >>>>> to the >>>> the >>>>> user.xml and redirect to the profile page for setting additional >>>> information >>>>> (email, full name and section edition etc) >>>>> >>>>> - Adding page permission should lookup if the group or the user >>>>> exist. >>>>> >>>>> - Adding users to a wiki group should only be possible for >>>>> existing >>>> users. >>>>> >>>>> /Thomas >>>>> >>>>> >>>>> On Oct 24, 2009, at 10:57 , Jim Willeke wrote: >>>>> >>>>>> Why allow people to eliminate the user.xml? >>>>>> >>>>>> Why not allow the use of LDAP for the user profile? >>>>>> >>>>>> Allow mapping the LDAP attributes to the profile values? >>>>>> >>>>>> Enterprises have no desire to maintain another separate user >>>>>> store of >>>>>> information. Many already have a central LDAP store. >>>>>> >>>>>> -jim >>>>>> Jim Willeke >>>>>> >>>>>> >>>>>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt >>>>>> <te@zama.org> >>>> wrote: >>>>>> >>>>>>> I would suggest a change, if a ldap user is logging the first >>>>>>> time. >>>> the >>>>>>> Wiki should create the user in the user.xml - it gives a lot >>>>>>> of problem >>>>>>> when >>>>>>> adding a ldap user to a wiki group, since it possible that the >>>>>>> user >>>> isn't >>>>>>> created. >>>>>>> >>>>>>> >>>>>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: >>>>>>> >>>>>>> If a user creates a user profile after logging into the >>>>>>> container, he >>>> or >>>>>>>> >>>>>>>> she will have an opportunity to specify a "full name." If a >>>>>>>> full name >>>> is >>>>>>>> supplied, it will be used in page histories etc from that point >>>> forward. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@hkr.at >>>>>>>> > >>>> wrote: >>>>>>>> >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>> >>>>>>>>> Hash: SHA256 >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> I run JSPWiki with Web Container Authentication via LDAP and >>>>>>>>> it runs >>>>>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK >>>>>>>>> 6). >>>>>>>>> >>>>>>>>> Only the visualization of real user name is still missing. I >>>>>>>>> get only >>>>>>>>> the login name (short name) instead of the full name in the >>>>>>>>> change >>>>>>>>> history and so on. Is it a default behaviour or >>>>>>>>> misconfiguration? >>>>>>>>> >>>>>>>>> Nice greetings, >>>>>>>>> Harald >>>>>>>>> >>>>>>>>> - -- >>>>>>>>> >>>>>>>>> Harald Krammer >>>>>>>>> Brucknerstrasse 33 >>>>>>>>> A - 4020 Linz >>>>>>>>> AUSTRIA >>>>>>>>> >>>>>>>>> Mobil +43.(0) 664. 130 59 58 >>>>>>>>> Mail: Harald.Krammer (at) hkr.at >>>>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>>>> Version: GnuPG v1.4.9 (GNU/Linux) >>>>>>>>> >>>>>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/ >>>>>>>>> HrqMiWfZ >>>>>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 >>>>>>>>> =Kd7Y >>>>>>>>> -----END PGP SIGNATURE----- >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>>
Sorry-- I fat-fingered the send button! Anyhow, with the LdapUserDatabase you won't need to provision or deprovision because everything will be in LDAP. We will keep some data locally (user prefs) but that's it. At this point, if you still have concerns I'd recommend yo On Oct 25, 2009, at 7:04, Andrew Jaquith <andrew.r.jaquith@gmail.com> wrote: > I should not have used the magic word "provision" in my last post. > The important concept is that when the LdapUserDatabase is used, > LDAP *is* the user database > > On Oct 25, 2009, at 6:38, Jim Willeke <jim@willeke.com> wrote: > >> But what about de-provisioning users? >> >> The issue with putting users in yet another database in the >> enterprise world >> central provisioning, de-provisioning and RBAC are the strategic >> directions >> with no desire to mange users in remote stores. >> >> And why would someone want to put in information into the WIKI when >> it is >> already been add to the user in LDAP via the enterprise portal? >> >> I will agree the local "groups" concept is necessary, but it should >> be an >> agumnetation to container managed security that most enterprises >> would >> utilize. >> >> So users in the role (perhaps by department) "Sales" would always >> be able to >> view any pages with "Sales": >> >> Then the local "groups" would be done to perform "teaming" >> arrangements as >> would be done in a project that would cross departmental lines. >> >> -jim >> Jim Willeke >> >> >> On Sat, Oct 24, 2009 at 11:12 AM, Andrew Jaquith <andrew.r.jaquith@gmail.com >>> wrote: >> >>> JSPWiki 3.0 trunk already has an LdapUserDatabase and >>> LdapAuthorizer, >>> which means that it can obtain user profiles on a read-only basis >>> from >>> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your >>> users will be "provisioned" in JSPWiki automatically. This should >>> solve the user-experience problem you described. >>> >>> The upcoming 3.0 LDAP features have been developed and tested with >>> Active Directory and OpenLDAP. It is configured via the GUI at >>> install-time. >>> >>> With respect to permissions and group memberships: these are good >>> suggestions. We still have some work to do for the GUI for ACLs for >>> 3.0. I agree that we should be validating user names when users >>> create >>> the ACLs. Same for adding users to groups. These suggestions will be >>> incorporated into how the ACL GUIs work -- likely via AJAX in >>> real-time. >>> >>> Andrew >>> >>> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@zama.org> >>> wrote: >>>> The group and permission system in the jspwiki is rather dynamic, >>>> and >>> ldaps >>>> tends to be readonly except for a groups of administrators. There >>>> for >>> there >>>> is still need for the user.xml and group.xml. But in my opinion the >>> user.xml >>>> needs to be automatically updated when a new ldap user is logged >>>> in. >>>> >>>> Otherwise granting and managing jspwiki permissions i a >>>> nightmare, this >>> also >>>> enhanced since there is no check on if a user exist - when adding >>>> users >>> to >>>> wiki group or setting a page permission. >>>> >>>> I think the following should be changed. >>>> >>>> - First time a new user is logged in - the user should be added >>>> to the >>> the >>>> user.xml and redirect to the profile page for setting additional >>> information >>>> (email, full name and section edition etc) >>>> >>>> - Adding page permission should lookup if the group or the user >>>> exist. >>>> >>>> - Adding users to a wiki group should only be possible for existing >>> users. >>>> >>>> /Thomas >>>> >>>> >>>> On Oct 24, 2009, at 10:57 , Jim Willeke wrote: >>>> >>>>> Why allow people to eliminate the user.xml? >>>>> >>>>> Why not allow the use of LDAP for the user profile? >>>>> >>>>> Allow mapping the LDAP attributes to the profile values? >>>>> >>>>> Enterprises have no desire to maintain another separate user >>>>> store of >>>>> information. Many already have a central LDAP store. >>>>> >>>>> -jim >>>>> Jim Willeke >>>>> >>>>> >>>>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@zama.org> >>> wrote: >>>>> >>>>>> I would suggest a change, if a ldap user is logging the first >>>>>> time. >>> the >>>>>> Wiki should create the user in the user.xml - it gives a lot of >>>>>> problem >>>>>> when >>>>>> adding a ldap user to a wiki group, since it possible that the >>>>>> user >>> isn't >>>>>> created. >>>>>> >>>>>> >>>>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: >>>>>> >>>>>> If a user creates a user profile after logging into the >>>>>> container, he >>> or >>>>>>> >>>>>>> she will have an opportunity to specify a "full name." If a >>>>>>> full name >>> is >>>>>>> supplied, it will be used in page histories etc from that point >>> forward. >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> On Oct 22, 2009, at 16:34, Harald Krammer >>>>>>> <Harald.Krammer@hkr.at> >>> wrote: >>>>>>> >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> >>>>>>>> Hash: SHA256 >>>>>>>> >>>>>>>> Hello, >>>>>>>> I run JSPWiki with Web Container Authentication via LDAP and >>>>>>>> it runs >>>>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK >>>>>>>> 6). >>>>>>>> >>>>>>>> Only the visualization of real user name is still missing. I >>>>>>>> get only >>>>>>>> the login name (short name) instead of the full name in the >>>>>>>> change >>>>>>>> history and so on. Is it a default behaviour or >>>>>>>> misconfiguration? >>>>>>>> >>>>>>>> Nice greetings, >>>>>>>> Harald >>>>>>>> >>>>>>>> - -- >>>>>>>> >>>>>>>> Harald Krammer >>>>>>>> Brucknerstrasse 33 >>>>>>>> A - 4020 Linz >>>>>>>> AUSTRIA >>>>>>>> >>>>>>>> Mobil +43.(0) 664. 130 59 58 >>>>>>>> Mail: Harald.Krammer (at) hkr.at >>>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>>> Version: GnuPG v1.4.9 (GNU/Linux) >>>>>>>> >>>>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/ >>>>>>>> HrqMiWfZ >>>>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 >>>>>>>> =Kd7Y >>>>>>>> -----END PGP SIGNATURE----- >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>
I should not have used the magic word "provision" in my last post. The important concept is that when the LdapUserDatabase is used, LDAP *is* the user database On Oct 25, 2009, at 6:38, Jim Willeke <jim@willeke.com> wrote: > But what about de-provisioning users? > > The issue with putting users in yet another database in the > enterprise world > central provisioning, de-provisioning and RBAC are the strategic > directions > with no desire to mange users in remote stores. > > And why would someone want to put in information into the WIKI when > it is > already been add to the user in LDAP via the enterprise portal? > > I will agree the local "groups" concept is necessary, but it should > be an > agumnetation to container managed security that most enterprises would > utilize. > > So users in the role (perhaps by department) "Sales" would always be > able to > view any pages with "Sales": > > Then the local "groups" would be done to perform "teaming" > arrangements as > would be done in a project that would cross departmental lines. > > -jim > Jim Willeke > > > On Sat, Oct 24, 2009 at 11:12 AM, Andrew Jaquith <andrew.r.jaquith@gmail.com >> wrote: > >> JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer, >> which means that it can obtain user profiles on a read-only basis >> from >> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your >> users will be "provisioned" in JSPWiki automatically. This should >> solve the user-experience problem you described. >> >> The upcoming 3.0 LDAP features have been developed and tested with >> Active Directory and OpenLDAP. It is configured via the GUI at >> install-time. >> >> With respect to permissions and group memberships: these are good >> suggestions. We still have some work to do for the GUI for ACLs for >> 3.0. I agree that we should be validating user names when users >> create >> the ACLs. Same for adding users to groups. These suggestions will be >> incorporated into how the ACL GUIs work -- likely via AJAX in >> real-time. >> >> Andrew >> >> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@zama.org> >> wrote: >>> The group and permission system in the jspwiki is rather dynamic, >>> and >> ldaps >>> tends to be readonly except for a groups of administrators. There >>> for >> there >>> is still need for the user.xml and group.xml. But in my opinion the >> user.xml >>> needs to be automatically updated when a new ldap user is logged in. >>> >>> Otherwise granting and managing jspwiki permissions i a nightmare, >>> this >> also >>> enhanced since there is no check on if a user exist - when adding >>> users >> to >>> wiki group or setting a page permission. >>> >>> I think the following should be changed. >>> >>> - First time a new user is logged in - the user should be added to >>> the >> the >>> user.xml and redirect to the profile page for setting additional >> information >>> (email, full name and section edition etc) >>> >>> - Adding page permission should lookup if the group or the user >>> exist. >>> >>> - Adding users to a wiki group should only be possible for existing >> users. >>> >>> /Thomas >>> >>> >>> On Oct 24, 2009, at 10:57 , Jim Willeke wrote: >>> >>>> Why allow people to eliminate the user.xml? >>>> >>>> Why not allow the use of LDAP for the user profile? >>>> >>>> Allow mapping the LDAP attributes to the profile values? >>>> >>>> Enterprises have no desire to maintain another separate user >>>> store of >>>> information. Many already have a central LDAP store. >>>> >>>> -jim >>>> Jim Willeke >>>> >>>> >>>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@zama.org> >> wrote: >>>> >>>>> I would suggest a change, if a ldap user is logging the first >>>>> time. >> the >>>>> Wiki should create the user in the user.xml - it gives a lot of >>>>> problem >>>>> when >>>>> adding a ldap user to a wiki group, since it possible that the >>>>> user >> isn't >>>>> created. >>>>> >>>>> >>>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: >>>>> >>>>> If a user creates a user profile after logging into the >>>>> container, he >> or >>>>>> >>>>>> she will have an opportunity to specify a "full name." If a >>>>>> full name >> is >>>>>> supplied, it will be used in page histories etc from that point >> forward. >>>>>> >>>>>> Andrew >>>>>> >>>>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@hkr.at> >> wrote: >>>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> >>>>>>> Hash: SHA256 >>>>>>> >>>>>>> Hello, >>>>>>> I run JSPWiki with Web Container Authentication via LDAP and >>>>>>> it runs >>>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). >>>>>>> >>>>>>> Only the visualization of real user name is still missing. I >>>>>>> get only >>>>>>> the login name (short name) instead of the full name in the >>>>>>> change >>>>>>> history and so on. Is it a default behaviour or >>>>>>> misconfiguration? >>>>>>> >>>>>>> Nice greetings, >>>>>>> Harald >>>>>>> >>>>>>> - -- >>>>>>> >>>>>>> Harald Krammer >>>>>>> Brucknerstrasse 33 >>>>>>> A - 4020 Linz >>>>>>> AUSTRIA >>>>>>> >>>>>>> Mobil +43.(0) 664. 130 59 58 >>>>>>> Mail: Harald.Krammer (at) hkr.at >>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>> Version: GnuPG v1.4.9 (GNU/Linux) >>>>>>> >>>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ >>>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 >>>>>>> =Kd7Y >>>>>>> -----END PGP SIGNATURE----- >>>>>>> >>>>>> >>>>> >>> >>> >>
It is still too early. I don't have an estimate of when you can start testing. We would Iike to get an alpha out soon, obviously. On Oct 25, 2009, at 5:30, Harald Krammer <Harald.Krammer@hkr.at> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > That sounds interesting. > It is noted that the trunk is heavily under construction and the > code is > broken. Does it make sense to test current trunk version or is it > too early? > > Greetings, > Harald > > Andrew Jaquith schrieb: >> JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer, >> which means that it can obtain user profiles on a read-only basis >> from >> LDAP, and obtain roles from LDAP groups. So if you use LDAP, your >> users will be "provisioned" in JSPWiki automatically. This should >> solve the user-experience problem you described. >> >> The upcoming 3.0 LDAP features have been developed and tested with >> Active Directory and OpenLDAP. It is configured via the GUI at >> install-time. >> >> With respect to permissions and group memberships: these are good >> suggestions. We still have some work to do for the GUI for ACLs for >> 3.0. I agree that we should be validating user names when users >> create >> the ACLs. Same for adding users to groups. These suggestions will be >> incorporated into how the ACL GUIs work -- likely via AJAX in >> real-time. >> >> Andrew >> >> On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@zama.org> >> wrote: >>> The group and permission system in the jspwiki is rather dynamic, >>> and ldaps >>> tends to be readonly except for a groups of administrators. There >>> for there >>> is still need for the user.xml and group.xml. But in my opinion >>> the user.xml >>> needs to be automatically updated when a new ldap user is logged in. >>> >>> Otherwise granting and managing jspwiki permissions i a nightmare, >>> this also >>> enhanced since there is no check on if a user exist - when adding >>> users to >>> wiki group or setting a page permission. >>> >>> I think the following should be changed. >>> >>> - First time a new user is logged in - the user should be added to >>> the the >>> user.xml and redirect to the profile page for setting additional >>> information >>> (email, full name and section edition etc) >>> >>> - Adding page permission should lookup if the group or the user >>> exist. >>> >>> - Adding users to a wiki group should only be possible for >>> existing users. >>> >>> /Thomas >>> >>> >>> On Oct 24, 2009, at 10:57 , Jim Willeke wrote: >>> >>>> Why allow people to eliminate the user.xml? >>>> >>>> Why not allow the use of LDAP for the user profile? >>>> >>>> Allow mapping the LDAP attributes to the profile values? >>>> >>>> Enterprises have no desire to maintain another separate user >>>> store of >>>> information. Many already have a central LDAP store. >>>> >>>> -jim >>>> Jim Willeke >>>> >>>> >>>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt >>>> <te@zama.org> wrote: >>>> >>>>> I would suggest a change, if a ldap user is logging the first >>>>> time. the >>>>> Wiki should create the user in the user.xml - it gives a lot of >>>>> problem >>>>> when >>>>> adding a ldap user to a wiki group, since it possible that the >>>>> user isn't >>>>> created. >>>>> >>>>> >>>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: >>>>> >>>>> If a user creates a user profile after logging into the >>>>> container, he or >>>>>> she will have an opportunity to specify a "full name." If a >>>>>> full name is >>>>>> supplied, it will be used in page histories etc from that point >>>>>> forward. >>>>>> >>>>>> Andrew >>>>>> >>>>>> On Oct 22, 2009, at 16:34, Harald Krammer >>>>>> <Harald.Krammer@hkr.at> wrote: >>>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA256 >>>>>>> >>>>>>> Hello, >>>>>>> I run JSPWiki with Web Container Authentication via LDAP and >>>>>>> it runs >>>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). >>>>>>> >>>>>>> Only the visualization of real user name is still missing. I >>>>>>> get only >>>>>>> the login name (short name) instead of the full name in the >>>>>>> change >>>>>>> history and so on. Is it a default behaviour or >>>>>>> misconfiguration? >>>>>>> >>>>>>> Nice greetings, >>>>>>> Harald >>>>>>> >>>>>>> - -- >>>>>>> >>>>>>> Harald Krammer >>>>>>> Brucknerstrasse 33 >>>>>>> A - 4020 Linz >>>>>>> AUSTRIA >>>>>>> >>>>>>> Mobil +43.(0) 664. 130 59 58 >>>>>>> Mail: Harald.Krammer (at) hkr.at >>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>> Version: GnuPG v1.4.9 (GNU/Linux) >>>>>>> >>>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ >>>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 >>>>>>> =Kd7Y >>>>>>> -----END PGP SIGNATURE----- >>>>>>> >>> >> > > > - -- > > Harald Krammer > Brucknerstrasse 33 > A - 4020 Linz > AUSTRIA > > Mobil +43.(0) 664. 130 59 58 > Mail: Harald.Krammer (at) hkr.at > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEAREIAAYFAkrkGqEACgkQ9QlAsubHO9vsYACgriH34OZiGCZq6Ac2DayNJnd3 > SKQAni/X1DtibeNEbZKtnzNAe+OHUwt2 > =KwyM > -----END PGP SIGNATURE-----
But what about de-provisioning users? The issue with putting users in yet another database in the enterprise world central provisioning, de-provisioning and RBAC are the strategic directions with no desire to mange users in remote stores. And why would someone want to put in information into the WIKI when it is already been add to the user in LDAP via the enterprise portal? I will agree the local "groups" concept is necessary, but it should be an agumnetation to container managed security that most enterprises would utilize. So users in the role (perhaps by department) "Sales" would always be able to view any pages with "Sales": Then the local "groups" would be done to perform "teaming" arrangements as would be done in a project that would cross departmental lines. -jim Jim Willeke On Sat, Oct 24, 2009 at 11:12 AM, Andrew Jaquith <andrew.r.jaquith@gmail.com > wrote: > JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer, > which means that it can obtain user profiles on a read-only basis from > LDAP, and obtain roles from LDAP groups. So if you use LDAP, your > users will be "provisioned" in JSPWiki automatically. This should > solve the user-experience problem you described. > > The upcoming 3.0 LDAP features have been developed and tested with > Active Directory and OpenLDAP. It is configured via the GUI at > install-time. > > With respect to permissions and group memberships: these are good > suggestions. We still have some work to do for the GUI for ACLs for > 3.0. I agree that we should be validating user names when users create > the ACLs. Same for adding users to groups. These suggestions will be > incorporated into how the ACL GUIs work -- likely via AJAX in > real-time. > > Andrew > > On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@zama.org> wrote: > > The group and permission system in the jspwiki is rather dynamic, and > ldaps > > tends to be readonly except for a groups of administrators. There for > there > > is still need for the user.xml and group.xml. But in my opinion the > user.xml > > needs to be automatically updated when a new ldap user is logged in. > > > > Otherwise granting and managing jspwiki permissions i a nightmare, this > also > > enhanced since there is no check on if a user exist - when adding users > to > > wiki group or setting a page permission. > > > > I think the following should be changed. > > > > - First time a new user is logged in - the user should be added to the > the > > user.xml and redirect to the profile page for setting additional > information > > (email, full name and section edition etc) > > > > - Adding page permission should lookup if the group or the user exist. > > > > - Adding users to a wiki group should only be possible for existing > users. > > > > /Thomas > > > > > > On Oct 24, 2009, at 10:57 , Jim Willeke wrote: > > > >> Why allow people to eliminate the user.xml? > >> > >> Why not allow the use of LDAP for the user profile? > >> > >> Allow mapping the LDAP attributes to the profile values? > >> > >> Enterprises have no desire to maintain another separate user store of > >> information. Many already have a central LDAP store. > >> > >> -jim > >> Jim Willeke > >> > >> > >> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@zama.org> > wrote: > >> > >>> I would suggest a change, if a ldap user is logging the first time. > the > >>> Wiki should create the user in the user.xml - it gives a lot of problem > >>> when > >>> adding a ldap user to a wiki group, since it possible that the user > isn't > >>> created. > >>> > >>> > >>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: > >>> > >>> If a user creates a user profile after logging into the container, he > or > >>>> > >>>> she will have an opportunity to specify a "full name." If a full name > is > >>>> supplied, it will be used in page histories etc from that point > forward. > >>>> > >>>> Andrew > >>>> > >>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@hkr.at> > wrote: > >>>> > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>> > >>>>> Hash: SHA256 > >>>>> > >>>>> Hello, > >>>>> I run JSPWiki with Web Container Authentication via LDAP and it runs > >>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). > >>>>> > >>>>> Only the visualization of real user name is still missing. I get only > >>>>> the login name (short name) instead of the full name in the change > >>>>> history and so on. Is it a default behaviour or misconfiguration? > >>>>> > >>>>> Nice greetings, > >>>>> Harald > >>>>> > >>>>> - -- > >>>>> > >>>>> Harald Krammer > >>>>> Brucknerstrasse 33 > >>>>> A - 4020 Linz > >>>>> AUSTRIA > >>>>> > >>>>> Mobil +43.(0) 664. 130 59 58 > >>>>> Mail: Harald.Krammer (at) hkr.at > >>>>> -----BEGIN PGP SIGNATURE----- > >>>>> Version: GnuPG v1.4.9 (GNU/Linux) > >>>>> > >>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ > >>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 > >>>>> =Kd7Y > >>>>> -----END PGP SIGNATURE----- > >>>>> > >>>> > >>> > > > > >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 That sounds interesting. It is noted that the trunk is heavily under construction and the code is broken. Does it make sense to test current trunk version or is it too early? Greetings, Harald Andrew Jaquith schrieb: > JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer, > which means that it can obtain user profiles on a read-only basis from > LDAP, and obtain roles from LDAP groups. So if you use LDAP, your > users will be "provisioned" in JSPWiki automatically. This should > solve the user-experience problem you described. > > The upcoming 3.0 LDAP features have been developed and tested with > Active Directory and OpenLDAP. It is configured via the GUI at > install-time. > > With respect to permissions and group memberships: these are good > suggestions. We still have some work to do for the GUI for ACLs for > 3.0. I agree that we should be validating user names when users create > the ACLs. Same for adding users to groups. These suggestions will be > incorporated into how the ACL GUIs work -- likely via AJAX in > real-time. > > Andrew > > On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@zama.org> wrote: >> The group and permission system in the jspwiki is rather dynamic, and ldaps >> tends to be readonly except for a groups of administrators. There for there >> is still need for the user.xml and group.xml. But in my opinion the user.xml >> needs to be automatically updated when a new ldap user is logged in. >> >> Otherwise granting and managing jspwiki permissions i a nightmare, this also >> enhanced since there is no check on if a user exist - when adding users to >> wiki group or setting a page permission. >> >> I think the following should be changed. >> >> - First time a new user is logged in - the user should be added to the the >> user.xml and redirect to the profile page for setting additional information >> (email, full name and section edition etc) >> >> - Adding page permission should lookup if the group or the user exist. >> >> - Adding users to a wiki group should only be possible for existing users. >> >> /Thomas >> >> >> On Oct 24, 2009, at 10:57 , Jim Willeke wrote: >> >>> Why allow people to eliminate the user.xml? >>> >>> Why not allow the use of LDAP for the user profile? >>> >>> Allow mapping the LDAP attributes to the profile values? >>> >>> Enterprises have no desire to maintain another separate user store of >>> information. Many already have a central LDAP store. >>> >>> -jim >>> Jim Willeke >>> >>> >>> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@zama.org> wrote: >>> >>>> I would suggest a change, if a ldap user is logging the first time. the >>>> Wiki should create the user in the user.xml - it gives a lot of problem >>>> when >>>> adding a ldap user to a wiki group, since it possible that the user isn't >>>> created. >>>> >>>> >>>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: >>>> >>>> If a user creates a user profile after logging into the container, he or >>>>> she will have an opportunity to specify a "full name." If a full name is >>>>> supplied, it will be used in page histories etc from that point forward. >>>>> >>>>> Andrew >>>>> >>>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@hkr.at> wrote: >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA256 >>>>>> >>>>>> Hello, >>>>>> I run JSPWiki with Web Container Authentication via LDAP and it runs >>>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). >>>>>> >>>>>> Only the visualization of real user name is still missing. I get only >>>>>> the login name (short name) instead of the full name in the change >>>>>> history and so on. Is it a default behaviour or misconfiguration? >>>>>> >>>>>> Nice greetings, >>>>>> Harald >>>>>> >>>>>> - -- >>>>>> >>>>>> Harald Krammer >>>>>> Brucknerstrasse 33 >>>>>> A - 4020 Linz >>>>>> AUSTRIA >>>>>> >>>>>> Mobil +43.(0) 664. 130 59 58 >>>>>> Mail: Harald.Krammer (at) hkr.at >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG v1.4.9 (GNU/Linux) >>>>>> >>>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ >>>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 >>>>>> =Kd7Y >>>>>> -----END PGP SIGNATURE----- >>>>>> >> > - -- Harald Krammer Brucknerstrasse 33 A - 4020 Linz AUSTRIA Mobil +43.(0) 664. 130 59 58 Mail: Harald.Krammer (at) hkr.at -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkrkGqEACgkQ9QlAsubHO9vsYACgriH34OZiGCZq6Ac2DayNJnd3 SKQAni/X1DtibeNEbZKtnzNAe+OHUwt2 =KwyM -----END PGP SIGNATURE-----
JSPWiki 3.0 trunk already has an LdapUserDatabase and LdapAuthorizer, which means that it can obtain user profiles on a read-only basis from LDAP, and obtain roles from LDAP groups. So if you use LDAP, your users will be "provisioned" in JSPWiki automatically. This should solve the user-experience problem you described. The upcoming 3.0 LDAP features have been developed and tested with Active Directory and OpenLDAP. It is configured via the GUI at install-time. With respect to permissions and group memberships: these are good suggestions. We still have some work to do for the GUI for ACLs for 3.0. I agree that we should be validating user names when users create the ACLs. Same for adding users to groups. These suggestions will be incorporated into how the ACL GUIs work -- likely via AJAX in real-time. Andrew On Sat, Oct 24, 2009 at 7:25 AM, Thomas Engelschmidt <te@zama.org> wrote: > The group and permission system in the jspwiki is rather dynamic, and ldaps > tends to be readonly except for a groups of administrators. There for there > is still need for the user.xml and group.xml. But in my opinion the user.xml > needs to be automatically updated when a new ldap user is logged in. > > Otherwise granting and managing jspwiki permissions i a nightmare, this also > enhanced since there is no check on if a user exist - when adding users to > wiki group or setting a page permission. > > I think the following should be changed. > > - First time a new user is logged in - the user should be added to the the > user.xml and redirect to the profile page for setting additional information > (email, full name and section edition etc) > > - Adding page permission should lookup if the group or the user exist. > > - Adding users to a wiki group should only be possible for existing users. > > /Thomas > > > On Oct 24, 2009, at 10:57 , Jim Willeke wrote: > >> Why allow people to eliminate the user.xml? >> >> Why not allow the use of LDAP for the user profile? >> >> Allow mapping the LDAP attributes to the profile values? >> >> Enterprises have no desire to maintain another separate user store of >> information. Many already have a central LDAP store. >> >> -jim >> Jim Willeke >> >> >> On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@zama.org> wrote: >> >>> I would suggest a change, if a ldap user is logging the first time. the >>> Wiki should create the user in the user.xml - it gives a lot of problem >>> when >>> adding a ldap user to a wiki group, since it possible that the user isn't >>> created. >>> >>> >>> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: >>> >>> If a user creates a user profile after logging into the container, he or >>>> >>>> she will have an opportunity to specify a "full name." If a full name is >>>> supplied, it will be used in page histories etc from that point forward. >>>> >>>> Andrew >>>> >>>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@hkr.at> wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> >>>>> Hash: SHA256 >>>>> >>>>> Hello, >>>>> I run JSPWiki with Web Container Authentication via LDAP and it runs >>>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). >>>>> >>>>> Only the visualization of real user name is still missing. I get only >>>>> the login name (short name) instead of the full name in the change >>>>> history and so on. Is it a default behaviour or misconfiguration? >>>>> >>>>> Nice greetings, >>>>> Harald >>>>> >>>>> - -- >>>>> >>>>> Harald Krammer >>>>> Brucknerstrasse 33 >>>>> A - 4020 Linz >>>>> AUSTRIA >>>>> >>>>> Mobil +43.(0) 664. 130 59 58 >>>>> Mail: Harald.Krammer (at) hkr.at >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v1.4.9 (GNU/Linux) >>>>> >>>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ >>>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 >>>>> =Kd7Y >>>>> -----END PGP SIGNATURE----- >>>>> >>>> >>> > >
The group and permission system in the jspwiki is rather dynamic, and ldaps tends to be readonly except for a groups of administrators. There for there is still need for the user.xml and group.xml. But in my opinion the user.xml needs to be automatically updated when a new ldap user is logged in. Otherwise granting and managing jspwiki permissions i a nightmare, this also enhanced since there is no check on if a user exist - when adding users to wiki group or setting a page permission. I think the following should be changed. - First time a new user is logged in - the user should be added to the the user.xml and redirect to the profile page for setting additional information (email, full name and section edition etc) - Adding page permission should lookup if the group or the user exist. - Adding users to a wiki group should only be possible for existing users. /Thomas On Oct 24, 2009, at 10:57 , Jim Willeke wrote: > Why allow people to eliminate the user.xml? > > Why not allow the use of LDAP for the user profile? > > Allow mapping the LDAP attributes to the profile values? > > Enterprises have no desire to maintain another separate user store of > information. Many already have a central LDAP store. > > -jim > Jim Willeke > > > On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@zama.org> > wrote: > >> I would suggest a change, if a ldap user is logging the first >> time. the >> Wiki should create the user in the user.xml - it gives a lot of >> problem when >> adding a ldap user to a wiki group, since it possible that the user >> isn't >> created. >> >> >> On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: >> >> If a user creates a user profile after logging into the container, >> he or >>> she will have an opportunity to specify a "full name." If a full >>> name is >>> supplied, it will be used in page histories etc from that point >>> forward. >>> >>> Andrew >>> >>> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@hkr.at> >>> wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> Hello, >>>> I run JSPWiki with Web Container Authentication via LDAP and it >>>> runs >>>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). >>>> >>>> Only the visualization of real user name is still missing. I get >>>> only >>>> the login name (short name) instead of the full name in the change >>>> history and so on. Is it a default behaviour or misconfiguration? >>>> >>>> Nice greetings, >>>> Harald >>>> >>>> - -- >>>> >>>> Harald Krammer >>>> Brucknerstrasse 33 >>>> A - 4020 Linz >>>> AUSTRIA >>>> >>>> Mobil +43.(0) 664. 130 59 58 >>>> Mail: Harald.Krammer (at) hkr.at >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.9 (GNU/Linux) >>>> >>>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ >>>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 >>>> =Kd7Y >>>> -----END PGP SIGNATURE----- >>>> >>> >>
Why allow people to eliminate the user.xml? Why not allow the use of LDAP for the user profile? Allow mapping the LDAP attributes to the profile values? Enterprises have no desire to maintain another separate user store of information. Many already have a central LDAP store. -jim Jim Willeke On Fri, Oct 23, 2009 at 2:09 PM, Thomas Engelschmidt <te@zama.org> wrote: > I would suggest a change, if a ldap user is logging the first time. the > Wiki should create the user in the user.xml - it gives a lot of problem when > adding a ldap user to a wiki group, since it possible that the user isn't > created. > > > On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: > > If a user creates a user profile after logging into the container, he or >> she will have an opportunity to specify a "full name." If a full name is >> supplied, it will be used in page histories etc from that point forward. >> >> Andrew >> >> On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@hkr.at> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> Hello, >>> I run JSPWiki with Web Container Authentication via LDAP and it runs >>> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). >>> >>> Only the visualization of real user name is still missing. I get only >>> the login name (short name) instead of the full name in the change >>> history and so on. Is it a default behaviour or misconfiguration? >>> >>> Nice greetings, >>> Harald >>> >>> - -- >>> >>> Harald Krammer >>> Brucknerstrasse 33 >>> A - 4020 Linz >>> AUSTRIA >>> >>> Mobil +43.(0) 664. 130 59 58 >>> Mail: Harald.Krammer (at) hkr.at >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.9 (GNU/Linux) >>> >>> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ >>> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 >>> =Kd7Y >>> -----END PGP SIGNATURE----- >>> >> >
I would suggest a change, if a ldap user is logging the first time. the Wiki should create the user in the user.xml - it gives a lot of problem when adding a ldap user to a wiki group, since it possible that the user isn't created. On Oct 23, 2009, at 00:38 , Andrew Jaquith wrote: > If a user creates a user profile after logging into the container, > he or she will have an opportunity to specify a "full name." If a > full name is supplied, it will be used in page histories etc from > that point forward. > > Andrew > > On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@hkr.at> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Hello, >> I run JSPWiki with Web Container Authentication via LDAP and it runs >> fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). >> >> Only the visualization of real user name is still missing. I get only >> the login name (short name) instead of the full name in the change >> history and so on. Is it a default behaviour or misconfiguration? >> >> Nice greetings, >> Harald >> >> - -- >> >> Harald Krammer >> Brucknerstrasse 33 >> A - 4020 Linz >> AUSTRIA >> >> Mobil +43.(0) 664. 130 59 58 >> Mail: Harald.Krammer (at) hkr.at >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> >> iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ >> w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 >> =Kd7Y >> -----END PGP SIGNATURE-----
If a user creates a user profile after logging into the container, he or she will have an opportunity to specify a "full name." If a full name is supplied, it will be used in page histories etc from that point forward. Andrew On Oct 22, 2009, at 16:34, Harald Krammer <Harald.Krammer@hkr.at> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello, > I run JSPWiki with Web Container Authentication via LDAP and it runs > fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). > > Only the visualization of real user name is still missing. I get only > the login name (short name) instead of the full name in the change > history and so on. Is it a default behaviour or misconfiguration? > > Nice greetings, > Harald > > - -- > > Harald Krammer > Brucknerstrasse 33 > A - 4020 Linz > AUSTRIA > > Mobil +43.(0) 664. 130 59 58 > Mail: Harald.Krammer (at) hkr.at > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ > w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 > =Kd7Y > -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I run JSPWiki with Web Container Authentication via LDAP and it runs fine (JSPWIki 2.8.2, OpenLDAP 2.4.11, Apache 6.0.20, OpenJDK 6). Only the visualization of real user name is still missing. I get only the login name (short name) instead of the full name in the change history and so on. Is it a default behaviour or misconfiguration? Nice greetings, Harald - -- Harald Krammer Brucknerstrasse 33 A - 4020 Linz AUSTRIA Mobil +43.(0) 664. 130 59 58 Mail: Harald.Krammer (at) hkr.at -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkrgwegACgkQ9QlAsubHO9vd7QCfT5rEQYRsPUAVvbs/HrqMiWfZ w6cAnjEp4FKX+3T3szBwW1n+DbCMd0z0 =Kd7Y -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Janne, no, I didn't know that. This illegal characters are included on a external URL. Thanks it works. Greetings, Harald Janne Jalkanen schrieb: > > You gotta realize that "[" and "]" are illegal characters in URLs. So > you need to replace them with their percent-encoding versions (which > your browser might do automatically), just like what you would do with > regular HTML. > > %5B = [ > %5D = ] > > /Janne > > On Oct 19, 2009, at 22:19 , Harald Krammer wrote: > > Hello, > what's is the right method to add links with '['or ']' symbols into > JSPWiki? > > e.g. http://foo.bar/?balbal[problemcmd]blabla[moreproblems] > > Solution like [my link; > http://foo.bar/?balbal[problemcmd]blabla[moreproblems]] doesn't work. > > Any helps are welcome > Harald - -- Harald Krammer Brucknerstrasse 33 A - 4020 Linz AUSTRIA Mobil +43.(0) 664. 130 59 58 Mail: Harald.Krammer (at) hkr.at -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkrd+isACgkQ9QlAsubHO9u3LgCfQ2PgKzwll3yxcqHBuuMSjTHJ rqYAnjHBIV6BUgwt5k7868mSQgtJGZku =sEW0 -----END PGP SIGNATURE-----
You gotta realize that "[" and "]" are illegal characters in URLs. So you need to replace them with their percent-encoding versions (which your browser might do automatically), just like what you would do with regular HTML. %5B = [ %5D = ] /Janne On Oct 19, 2009, at 22:19 , Harald Krammer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello, > what's is the right method to add links with '['or ']' symbols into > JSPWiki? > > e.g. http://foo.bar/?balbal[problemcmd]blabla[moreproblems] > > Solution like [my link; > http://foo.bar/?balbal[problemcmd]blabla[moreproblems]] doesn't work. > > Any helps are welcome > Harald > - -- > > Harald Krammer > Brucknerstrasse 33 > A - 4020 Linz > AUSTRIA > > Mobil +43.(0) 664. 130 59 58 > Mail: Harald.Krammer (at) hkr.at > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEAREIAAYFAkrcu7QACgkQ9QlAsubHO9u1jwCcDoQ+x0wty/MoTQE9f+W3chJM > BXsAn08HdYsENP+kgTFA1AjJNgouVl5c > =5Juu > -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, what's is the right method to add links with '['or ']' symbols into JSPWiki? e.g. http://foo.bar/?balbal[problemcmd]blabla[moreproblems] Solution like [my link; http://foo.bar/?balbal[problemcmd]blabla[moreproblems]] doesn't work. Any helps are welcome Harald - -- Harald Krammer Brucknerstrasse 33 A - 4020 Linz AUSTRIA Mobil +43.(0) 664. 130 59 58 Mail: Harald.Krammer (at) hkr.at -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkrcu7QACgkQ9QlAsubHO9u1jwCcDoQ+x0wty/MoTQE9f+W3chJM BXsAn08HdYsENP+kgTFA1AjJNgouVl5c =5Juu -----END PGP SIGNATURE-----
Do you have the connector using the correct parameters for the keystore?
The entries should/could be something like:
<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
<Connector port="8443"
maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false"
disableUploadTimeout="true"
debug="99"
acceptCount="100"
scheme="https"
secure="true"
keystoreFile="<keystore_filename>"
keystorePass="changeit"
truststoreFile="<trustcacerts-filename>"
truststorePass="changeit"
clientAuth="false"
sslProtocol="TLS" />
-jim
Jim Willeke
On Wed, Oct 14, 2009 at 5:19 PM, Andrew Jaquith
<andrew.r.jaquith@gmail.com>wrote:
> I don't know what to tell you, exactly. You can try troubleshooting
> Tomcat's SSL connection by adding this to your CATALINA_OPTS
> environment variable:
>
> -Djavax.net.debug=all
>
> You'll see a LOT of diagnostic information as a result. You can also
> fine-tune SSL debugging so you just see trust-store issues, for
> example. See the docs here:
>
> http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/ReadDebug.html
>
> If that doesn't work, then you likely have deeper LDAP connectivity
> problems than just SSL certificates. You should figure out what those
> are before proceeding further with the Java certificate store
> troubleshooting.
>
> What you should do in that case is use a different LDAP client (for
> example, the Unix 'ldapsearch' command line tool) to verify that you
> can connect to LDAP outside of Tomcat. Once you know the exact base
> DN, search string, SSL setting, etc to use, you'll know how to
> configure it in Tomcat.
>
> I can't give you much more guidance than that. Please don't ask for
> detailed HOWTOs on either of these points -- Google is your friend,
> and will be friendlier to you than I am willing to be at this point.
> Frankly, this is not really a JSPWiki issue -- it's a Tomcat issue.
> You might also want to try the tomcat-user mailing list.
>
> Andrew
>
> On Mon, Oct 12, 2009 at 4:54 AM, anilkumarkatta
> <anilkumarkatta@gmail.com> wrote:
> >
> > yes, i did.
> >
> > I have multiple installation on my machine with different versions of the
> > JVM. I installed the new certicates using InstallCert.java program as
> > suggested and crosschecked those intalled cert in the cercert file using
> > keytool list command.
> >
> > still the same issue. does the application war require any .jks files or
> > .cer file. ?
> >
> > Please advice
> >
> >
> > Jim Willeke wrote:
> >>
> >> Did you look in the jre?
> >>
> >> If you are using a JDK then the file would be:
> >> \jdk1.6.0_14\jre\lib\security\cacerts
> >>
> >>
> >> -jim
> >> Jim Willeke
> >>
> >>
> >> On Fri, Oct 9, 2009 at 5:51 AM, anilkumarkatta
> >> <anilkumarkatta@gmail.com>wrote:
> >>
> >>>
> >>>
> >>> Hi All
> >>>
> >>> Thanks for you replies.
> >>>
> >>> I have tried installing the ssl for the url. but same issue.
> >>>
> >>> I took some time to check how the existing url's ssl is done in
> >>> keystore..
> >>> but find nothing in java_home/lib/security.
> >>>
> >>> how this can be no ssl certifcates in keystore?
> >>>
> >>> if they keystore is exists in app level where does it saved in
> >>> application
> >>>
> >>> Thanks again for the replies.
> >>>
> >>> -Anil
> >>>
> >>>
> >>> Andrew Jaquith-4 wrote:
> >>> >
> >>> > You are pretty new to this whole Java thing aren't you?
> >>> >
> >>> > It appears that 1) your LDAP server requires SSL (a good thing!) and
> >>> > that 2) your LDAP's SSL certificate is self-signed and therefore not
> >>> > trusted.
> >>> >
> >>> > Java keeps an internal list of SSL certs it trusts. Your self-signed
> >>> > CA is not one of them. You need to add the SSL certificate CA (that
> >>> > is, the self-signed root) to your local JSSE trusted certificate
> >>> > store. This is at $JAVA_HOME/lib/security/cacerts.
> >>> >
> >>> > The Java command line tool "keytool" can do this. You can also use
my
> >>> > SSLHelper class, part of my freshcookies-security.jar that ships with
> >>> > JSPWiki. Indeed, I wrote it for just this situation. See the docs at
> >>> > freshcookies.org
> >>> > for details.
> >>> >
> >>> > With either aproach, you will need appprpriate admin rights to modify
> >>> > the truststore.
> >>> >
> >>> > Andrew
> >>> >
> >>> > On Oct 6, 2009, at 8:29, anilkumarkatta <anilkumarkatta@gmail.com>
> >>> > wrote:
> >>> >
> >>> >>
> >>> >>
> >>> >> ....contd.
> >>> >> Caused by: javax.net.ssl.SSLHandshakeException:
> >>> >> sun.security.validator.ValidatorException: PKIX path building
> failed:
> >>> >> sun.security.provider.certpath.SunCertPathBuilderException: unable
> >>> >> to find
> >>> >> valid certification path to requested target
> >>> >>
> >>> >>
> >>> >> anilkumarkatta wrote:
> >>> >>>
> >>> >>> Hi All
> >>> >>>
> >>> >>> I have tried to authenticate via LDAP server with all the
> >>> >>> configuration
> >>> >>> procedure explained in the URL
> >>> >>> http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP
> >>> >>> with a user provided LDAP settings, I got firewall team to
get the
> >>> >>> secure
> >>> >>> port open from where application is talking to the LDAP.
> >>> >>>
> >>> >>> i am getting this exception while start of the application
> >>> >>>
> >>> >>>
> >>> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
> >>> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
> >>> >>> membership established, start level:4
> >>> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO
> >>> >>> org.apache.catalina.tribes.membership.McastService - Sleeping
for
> >>> >>> 1000
> >>> >>> milliseconds to establish cluster membership, start level:8
> >>> >>> 2009-10-06 22:14:05,581 [Thread-2] INFO
> >>> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping,
> >>> >>> membership established, start level:8
> >>> >>> 2009-10-06 22:14:06,144 [Thread-2] WARN
> >>> >>> org.apache.catalina.core.ContainerBase.[Catalina] - Exception
> >>> >>> performing
> >>> >>> authentication
> >>> >>> javax.naming.CommunicationException: simple bind failed:
> >>> >>> ARTE001.MYDOMAIN.AK.com:636 [Root exception is
> >>> >>> javax.net.ssl.SSLHandshakeException:
> >>> >>> sun.security.validator.ValidatorException: PKIX path building
> failed:
> >>> >>> sun.security.provider.certpath.SunCertPathBuilderException:
unable
> >>> >>> to find
> >>> >>> valid certification path to requested target]
> >>> >>> at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source)
> >>> >>> at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
> >>> >>> at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
> >>> >>>
> >>> >>>
> >>> >>> where as when I place other deatails of the LDAP its working
fine.
> >>> >>> does this required any cerification files like .jks files..
if so
> >>> >>> where
> >>> >>> shall I place them?
> >>> >>>
> >>> >>> your replies are most welcome
> >>> >>>
> >>> >>> Regards,
> >>> >>> -Anil Katta
> >>> >>>
> >>> >>
> >>> >> --
> >>> >> View this message in context:
> >>> >>
> >>>
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25767801.html
> >>> >> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>> >>
> >>> >
> >>> >
> >>>
> >>> --
> >>> View this message in context:
> >>>
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25818421.html
> >>> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>>
> >>>
> >>
> >>
> >
> > --
> > View this message in context:
> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25852406.html
> > Sent from the JspWiki - User mailing list archive at Nabble.com.
> >
> >
>
I don't know what to tell you, exactly. You can try troubleshooting Tomcat's SSL connection by adding this to your CATALINA_OPTS environment variable: -Djavax.net.debug=all You'll see a LOT of diagnostic information as a result. You can also fine-tune SSL debugging so you just see trust-store issues, for example. See the docs here: http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/ReadDebug.html If that doesn't work, then you likely have deeper LDAP connectivity problems than just SSL certificates. You should figure out what those are before proceeding further with the Java certificate store troubleshooting. What you should do in that case is use a different LDAP client (for example, the Unix 'ldapsearch' command line tool) to verify that you can connect to LDAP outside of Tomcat. Once you know the exact base DN, search string, SSL setting, etc to use, you'll know how to configure it in Tomcat. I can't give you much more guidance than that. Please don't ask for detailed HOWTOs on either of these points -- Google is your friend, and will be friendlier to you than I am willing to be at this point. Frankly, this is not really a JSPWiki issue -- it's a Tomcat issue. You might also want to try the tomcat-user mailing list. Andrew On Mon, Oct 12, 2009 at 4:54 AM, anilkumarkatta <anilkumarkatta@gmail.com> wrote: > > yes, i did. > > I have multiple installation on my machine with different versions of the > JVM. I installed the new certicates using InstallCert.java program as > suggested and crosschecked those intalled cert in the cercert file using > keytool list command. > > still the same issue. does the application war require any .jks files or > .cer file. ? > > Please advice > > > Jim Willeke wrote: >> >> Did you look in the jre? >> >> If you are using a JDK then the file would be: >> \jdk1.6.0_14\jre\lib\security\cacerts >> >> >> -jim >> Jim Willeke >> >> >> On Fri, Oct 9, 2009 at 5:51 AM, anilkumarkatta >> <anilkumarkatta@gmail.com>wrote: >> >>> >>> >>> Hi All >>> >>> Thanks for you replies. >>> >>> I have tried installing the ssl for the url. but same issue. >>> >>> I took some time to check how the existing url's ssl is done in >>> keystore.. >>> but find nothing in java_home/lib/security. >>> >>> how this can be no ssl certifcates in keystore? >>> >>> if they keystore is exists in app level where does it saved in >>> application >>> >>> Thanks again for the replies. >>> >>> -Anil >>> >>> >>> Andrew Jaquith-4 wrote: >>> > >>> > You are pretty new to this whole Java thing aren't you? >>> > >>> > It appears that 1) your LDAP server requires SSL (a good thing!) and >>> > that 2) your LDAP's SSL certificate is self-signed and therefore not >>> > trusted. >>> > >>> > Java keeps an internal list of SSL certs it trusts. Your self-signed >>> > CA is not one of them. You need to add the SSL certificate CA (that >>> > is, the self-signed root) to your local JSSE trusted certificate >>> > store. This is at $JAVA_HOME/lib/security/cacerts. >>> > >>> > The Java command line tool "keytool" can do this. You can also use my >>> > SSLHelper class, part of my freshcookies-security.jar that ships with >>> > JSPWiki. Indeed, I wrote it for just this situation. See the docs at >>> > freshcookies.org >>> > for details. >>> > >>> > With either aproach, you will need appprpriate admin rights to modify >>> > the truststore. >>> > >>> > Andrew >>> > >>> > On Oct 6, 2009, at 8:29, anilkumarkatta <anilkumarkatta@gmail.com> >>> > wrote: >>> > >>> >> >>> >> >>> >> ....contd. >>> >> Caused by: javax.net.ssl.SSLHandshakeException: >>> >> sun.security.validator.ValidatorException: PKIX path building failed: >>> >> sun.security.provider.certpath.SunCertPathBuilderException: unable >>> >> to find >>> >> valid certification path to requested target >>> >> >>> >> >>> >> anilkumarkatta wrote: >>> >>> >>> >>> Hi All >>> >>> >>> >>> I have tried to authenticate via LDAP server with all the >>> >>> configuration >>> >>> procedure explained in the URL >>> >>> http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP >>> >>> with a user provided LDAP settings, I got firewall team to get the >>> >>> secure >>> >>> port open from where application is talking to the LDAP. >>> >>> >>> >>> i am getting this exception while start of the application >>> >>> >>> >>> >>> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO >>> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping, >>> >>> membership established, start level:4 >>> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO >>> >>> org.apache.catalina.tribes.membership.McastService - Sleeping for >>> >>> 1000 >>> >>> milliseconds to establish cluster membership, start level:8 >>> >>> 2009-10-06 22:14:05,581 [Thread-2] INFO >>> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping, >>> >>> membership established, start level:8 >>> >>> 2009-10-06 22:14:06,144 [Thread-2] WARN >>> >>> org.apache.catalina.core.ContainerBase.[Catalina] - Exception >>> >>> performing >>> >>> authentication >>> >>> javax.naming.CommunicationException: simple bind failed: >>> >>> ARTE001.MYDOMAIN.AK.com:636 [Root exception is >>> >>> javax.net.ssl.SSLHandshakeException: >>> >>> sun.security.validator.ValidatorException: PKIX path building failed: >>> >>> sun.security.provider.certpath.SunCertPathBuilderException: unable >>> >>> to find >>> >>> valid certification path to requested target] >>> >>> at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source) >>> >>> at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source) >>> >>> at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source) >>> >>> >>> >>> >>> >>> where as when I place other deatails of the LDAP its working fine. >>> >>> does this required any cerification files like .jks files.. if so >>> >>> where >>> >>> shall I place them? >>> >>> >>> >>> your replies are most welcome >>> >>> >>> >>> Regards, >>> >>> -Anil Katta >>> >>> >>> >> >>> >> -- >>> >> View this message in context: >>> >> >>> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25767801.html >>> >> Sent from the JspWiki - User mailing list archive at Nabble.com. >>> >> >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25818421.html >>> Sent from the JspWiki - User mailing list archive at Nabble.com. >>> >>> >> >> > > -- > View this message in context: http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25852406.html > Sent from the JspWiki - User mailing list archive at Nabble.com. > >
This indeed looks very much like you are accessing your JSPWiki with a "wrong URL", a URL that is different from the baseURL configured in jspwiki.properties.(like Madu also suggested) Once you login, you are redirected to the baseURL and have to log in again. It has nothing todo with RACF. regards, Harry 2009/10/12 Ben Thompson <Ben.Thompson@nt.gov.au> > I have an interesting issue, with one user who has to logon twice to be > authenticated to JSPWiki. All the other 25 users, including myself do > not have this problem. We are running JSPWiki 2.8.2 with RACF for our > authentication, but it turns out that the user had the same problem > under JSPWiki 2.8.1 using JSPWiki's authentication. The users has to > logon twice to be authenticated to JSPWiki under both Explorer and > Firefox. We have removed all cookies from both Explorer and Firefox, > this has not made a difference. > > > > The step to logon are: > > * When at the JSPWiki home page, G'day (anonymous guest) appears > next to login. > > > > * click Login and Login page displays. > > > > * fill in RACF username & Password. > > > > * JSPWiki home page is displayed with G'day (anonymous guest) > appearing against the login again, user still does not have access. > > > > * Repeat the process by clicking on the login and login page > displays. > > > > * Fill in RACF username & Password , JSPWiki home page is > displayed with G'day, XXX(authenticated). And at this stage the user > can access the info in JSPWiki. > > > > Any ideas on what's going on here > > > > Thanks > > > > Benjamin Thompson > Systems Programmer > Data Centre Services > Northern Territory Government > > twitter:benthompsonau > ph (08) 89997693 > > > >
yes, i did. I have multiple installation on my machine with different versions of the JVM. I installed the new certicates using InstallCert.java program as suggested and crosschecked those intalled cert in the cercert file using keytool list command. still the same issue. does the application war require any .jks files or .cer file. ? Please advice Jim Willeke wrote: > > Did you look in the jre? > > If you are using a JDK then the file would be: > \jdk1.6.0_14\jre\lib\security\cacerts > > > -jim > Jim Willeke > > > On Fri, Oct 9, 2009 at 5:51 AM, anilkumarkatta > <anilkumarkatta@gmail.com>wrote: > >> >> >> Hi All >> >> Thanks for you replies. >> >> I have tried installing the ssl for the url. but same issue. >> >> I took some time to check how the existing url's ssl is done in >> keystore.. >> but find nothing in java_home/lib/security. >> >> how this can be no ssl certifcates in keystore? >> >> if they keystore is exists in app level where does it saved in >> application >> >> Thanks again for the replies. >> >> -Anil >> >> >> Andrew Jaquith-4 wrote: >> > >> > You are pretty new to this whole Java thing aren't you? >> > >> > It appears that 1) your LDAP server requires SSL (a good thing!) and >> > that 2) your LDAP's SSL certificate is self-signed and therefore not >> > trusted. >> > >> > Java keeps an internal list of SSL certs it trusts. Your self-signed >> > CA is not one of them. You need to add the SSL certificate CA (that >> > is, the self-signed root) to your local JSSE trusted certificate >> > store. This is at $JAVA_HOME/lib/security/cacerts. >> > >> > The Java command line tool "keytool" can do this. You can also use my >> > SSLHelper class, part of my freshcookies-security.jar that ships with >> > JSPWiki. Indeed, I wrote it for just this situation. See the docs at >> > freshcookies.org >> > for details. >> > >> > With either aproach, you will need appprpriate admin rights to modify >> > the truststore. >> > >> > Andrew >> > >> > On Oct 6, 2009, at 8:29, anilkumarkatta <anilkumarkatta@gmail.com> >> > wrote: >> > >> >> >> >> >> >> ....contd. >> >> Caused by: javax.net.ssl.SSLHandshakeException: >> >> sun.security.validator.ValidatorException: PKIX path building failed: >> >> sun.security.provider.certpath.SunCertPathBuilderException: unable >> >> to find >> >> valid certification path to requested target >> >> >> >> >> >> anilkumarkatta wrote: >> >>> >> >>> Hi All >> >>> >> >>> I have tried to authenticate via LDAP server with all the >> >>> configuration >> >>> procedure explained in the URL >> >>> http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP >> >>> with a user provided LDAP settings, I got firewall team to get the >> >>> secure >> >>> port open from where application is talking to the LDAP. >> >>> >> >>> i am getting this exception while start of the application >> >>> >> >>> >> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO >> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping, >> >>> membership established, start level:4 >> >>> 2009-10-06 22:14:04,581 [Thread-2] INFO >> >>> org.apache.catalina.tribes.membership.McastService - Sleeping for >> >>> 1000 >> >>> milliseconds to establish cluster membership, start level:8 >> >>> 2009-10-06 22:14:05,581 [Thread-2] INFO >> >>> org.apache.catalina.tribes.membership.McastService - Done sleeping, >> >>> membership established, start level:8 >> >>> 2009-10-06 22:14:06,144 [Thread-2] WARN >> >>> org.apache.catalina.core.ContainerBase.[Catalina] - Exception >> >>> performing >> >>> authentication >> >>> javax.naming.CommunicationException: simple bind failed: >> >>> ARTE001.MYDOMAIN.AK.com:636 [Root exception is >> >>> javax.net.ssl.SSLHandshakeException: >> >>> sun.security.validator.ValidatorException: PKIX path building failed: >> >>> sun.security.provider.certpath.SunCertPathBuilderException: unable >> >>> to find >> >>> valid certification path to requested target] >> >>> at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source) >> >>> at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source) >> >>> at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source) >> >>> >> >>> >> >>> where as when I place other deatails of the LDAP its working fine. >> >>> does this required any cerification files like .jks files.. if so >> >>> where >> >>> shall I place them? >> >>> >> >>> your replies are most welcome >> >>> >> >>> Regards, >> >>> -Anil Katta >> >>> >> >> >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25767801.html >> >> Sent from the JspWiki - User mailing list archive at Nabble.com. >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25818421.html >> Sent from the JspWiki - User mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Web-Container-Authentication-Via-LDAP-tp25767713p25852406.html Sent from the JspWiki - User mailing list archive at Nabble.com.
Given that JSPWiki doesn't ship out-of-the box with RACF support, would you mind describing your configuration in more detail? In particular, how is your authentication configured? Andrew On Sun, Oct 11, 2009 at 9:38 PM, Ben Thompson <Ben.Thompson@nt.gov.au> wrote: > I have an interesting issue, with one user who has to logon twice to be > authenticated to JSPWiki. All the other 25 users, including myself do > not have this problem. We are running JSPWiki 2.8.2 with RACF for our > authentication, but it turns out that the user had the same problem > under JSPWiki 2.8.1 using JSPWiki's authentication. The users has to > logon twice to be authenticated to JSPWiki under both Explorer and > Firefox. We have removed all cookies from both Explorer and Firefox, > this has not made a difference. > > > > The step to logon are: > > * When at the JSPWiki home page, G'day (anonymous guest) appears > next to login. > > > > * click Login and Login page displays. > > > > * fill in RACF username & Password. > > > > * JSPWiki home page is displayed with G'day (anonymous guest) > appearing against the login again, user still does not have access. > > > > * Repeat the process by clicking on the login and login page > displays. > > > > * Fill in RACF username & Password , JSPWiki home page is > displayed with G'day, XXX(authenticated). And at this stage the user > can access the info in JSPWiki. > > > > Any ideas on what's going on here > > > > Thanks > > > > Benjamin Thompson > Systems Programmer > Data Centre Services > Northern Territory Government > > twitter:benthompsonau > ph (08) 89997693 > > > >