[xwiki-users] yay for google chrome and Xwiki

2009-07-10 Thread Niels Mayer
Windows users can rejoice -- http://www.google.com/chrome -- Because they
work nicely together. Much faster/smoother. Unfortunately, to get it on
linux, you have to switch to google's
linuxhttp://news.cnet.com/8301-17939_109-10281744-2.html?tag=newsLeadStoriesArea.1.
I didn't realize chrome was worth bothering with until I understood all the
announcements, which is what got me to switch. (I still use Firefox on Linux
(via X protocol) to run firebug)... I think IE won't be able to
So far, the biggest new feature I get, other than blazing fast javascript,
 is that text boxes (e.g. comment panels, object-editor panels, etc) are
resizeable. (If it's in an accordion like in the object editor, you have
to collapse/reexpand to get the sizing correct if you make the window larger
than it's original display.)

Niels
http://nielsmayer.com
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users


Re: [xwiki-users] After uploading a picture or a file in wysiwyg editor, an error occurs

2009-07-10 Thread ArielWang

The problem has been solved.
I added the memory of tomcat.
Thank you for your help!
-- 
View this message in context: 
http://n2.nabble.com/After-uploading-a-picture-or-a-file-in-wysiwyg-editor%2C-an-error-occurs-tp3230130p3236082.html
Sent from the XWiki- Users mailing list archive at Nabble.com.
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users


Re: [xwiki-users] working captcha

2009-07-10 Thread Ajdin Brandic
Edward

Correct me if I'm wrong but as I mentioned in my first reply to your
post a hacker can use GET method to post registration request in the
URL.
The hacker can set the value of register to 1 and this will pass your
check and register.  As you already know having incorrect captcher
doesn't matter, new user still gets registered.  Try GET method
yourself!!!  I hope I'm wrong :-(

Ajdin
 

-Original Message-
From: users-boun...@xwiki.org [mailto:users-boun...@xwiki.org] On Behalf
Of Edward Laptop
Sent: 09 July 2009 15:22
To: XWiki Users
Subject: [xwiki-users] working captcha

Dear All

I have spent quite a few hours playing with the captcha trying to get it
to work. There were some useful posts on the new group, but none of them
was a complete solution.

The below has worked for me... hopefully it will prove useful to someone
else.

This code is taken from a fairly old xwiki that my client didn't want to
upgrade. It is based around registerinline.vm, which had previously been
edited to add a lot more fields. I am not an expert on OOP but got it to
work with a selection of conditional statements.

First declare the plugin - you have to make sure its enabled - but
apparently it is by default. if ($reg)... will evaluate to true/false
and if the value is negative its an error. You test the state of the
captcha using $captchaPlugin.verifyCaptcha(edit)  where edit is the
name - set much later on.

One of the problems was that the form would come back with the correct
messages eg it would tell you if the captcha filled in wrong, but the
new user would still be regsitered (assuming all the other fields filled
in correctly). By playing I found that input type=hidden
name=register
value=1/ was the key  - if value=1 then registration occurs, if
=0
then it doesn't. So put this in a conditional - which seems to only
depend on the captcha being ture/flase - which was odd, because I would
ahve thought you'd want to test with $reg as well. However, I couldn't
get it to work with $reg at this stage - reg=$reg usually prints out the
nunber - but at this point it just printed out ref=$reg...

Don't forget to put verifyCaptcha into the action of the form tag.

call the displayCaptcha pass the class name as register_captcha which
should map to the css classname to render the image with
$captchaPlugin.displayCaptcha(edit,register_captcha)
pass the name as edit
go to
http://host:port/xwiki/bin/edit/XWiki/XWikiPreferences?editor=object

find XWiki.XWikiPreferences[0]: XWiki.DefaultSkin select the values for
Anonymous: and Registered: as image or text - text gives you a simple
sum to fill in. There were 3 sets of each on mine, I set them all to
imgae or all to text


Anyway, back to work...




## declare the plugin

#set($captchaPlugin = $xwiki.jcaptcha)

#if(!$reg||$reg0 )
pWelcome ./p
  #end

#*
  if reg is true (ie form filled), but less than zero OR the captcha is
wrong *#

  #if(  ($reg  $reg=0) || !$captchaPlugin.verifyCaptcha(edit) )
#if($reg==-2)
  #error($msg.get('core.register.passwordMismatch'))
#elseif($reg==-3)
  #error($msg.get('core.register.userAlreadyExists'))
#elseif($reg==-4)
  #error($msg.get('core.register.invalidUsername'))
#elseif($reg==-8)
  #error($msg.get('core.register.userAlreadyExists'))
#else
  ##error($msg.get('core.register.registerFailed', [$reg]))
#error(The captcha field was filled in wrongly.)

#end
  #elseif($reg  $captchaPlugin.verifyCaptcha(edit))
#set($xwname = XWiki.${request.xwikiname})
#info($msg.get('core.register.successful',
[$xwiki.getUserName($xwname), $request.xwikiname]))
  #end

##form appears if reg is not true or its -ve or capatcha is wrong


  #if(!$reg||$reg0 || !$captchaPlugin.verifyCaptcha(edit) )
form id=register action=verifyCaptcha method=post
  div
input type=hidden name=template value=XWiki.XWikiUserTemplate /

##this is a key statement

#if ($captchaPlugin.verifyCaptcha(edit))
##set it to 1
input type=hidden name=register value=1/ #else ##set it to 0
input type=hidden name=register value=0/ #end

 #set($class = $xwiki.getClass(XWiki.XWikiUsers))
#set($obj = $class.newObject())
#set($serverobj = $class.newObject())
#set($discard = $doc.use(XWiki.XWikiUsers))
#if($request.register_first_name)
  $doc.set(first_name, $request.register_first_name)
#end
#if($request.register_last_name)
  $doc.set(last_name, $request.register_last_name)
#end
dl

##username
  dt$msg.get(core.register.username)/dt
  ddinput name=xwikiname type=text size=20 onfocus=
prepareName(document.forms.register); //dd


... lots more fields


#if ($captchaPlugin)
  $captchaPlugin.displayCaptcha(edit,register_captcha)
#end


 span class=buttonwrapperinput type=submit
value=$msg.get(core.register.submit)//span/div



/form
  #end
___
users mailing list
users@xwiki.org

Re: [xwiki-users] Problem deploying war file to Glassfish v2.1

2009-07-10 Thread Brett M. Bergquist
I have this working on Glassfish 2.1.  There are other problems in the 
web.xml that don't conform to the DTD that I did not notice the first 
time I tried this.  Here is a working web.xml:

-- cut here --
?xml version=1.0 encoding=ISO-8859-1?
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee 
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
   version=2.4

  display-namexwiki/display-name
  descriptionXWiki Application/description
 
  !-- Restlet Application class name --
  context-param
param-nameorg.restlet.application/param-name
param-value
  org.xwiki.rest.XWikiRestletJaxRsApplication 
/param-value
  /context-param
 
  !-- Filter that sets a custom encoding to all requests, since usually 
clients don't specificy
   the encoding used for submitting the request, so by default 
containers fall back to the
   encoding globally configured in their settings. This allows XWiki 
to use a custom encoding,
   without affecting the whole container (and the other applications 
hosted). --
  filter
filter-nameSet Character Encoding/filter-name

filter-classcom.xpn.xwiki.web.SetCharacterEncodingFilter/filter-class
!-- The encoding to use. This must be the same as the one in 
xwiki.cfg (hopefully only one
 encoding will be used later). --
init-param
  param-nameencoding/param-name
  param-valueUTF-8/param-value
/init-param
!-- Whether to ignore and override the encoding specified by the 
client, when this actually
 happens. For example, AJAX requests made through 
XmlHttpRequests specify UTF-8. When this
 is set to false, the custom encoding is used only when there 
wasn't any encoding specified
 by the client. --
init-param
  param-nameignore/param-name
  param-valuefalse/param-value
/init-param
  /filter

  !-- A filter that allows requests to be saved and reused later. For 
example when the current request contains an expired
   authentication token, and the authorization module redirects to 
the login page, all the information sent by the
   client would be lost; this filter allows to save all that 
information, and after a successful login, injects the
   saved data in the new request. --
  filter
filter-nameRequestRestorer/filter-name

filter-classcom.xpn.xwiki.web.SavedRequestRestorerFilter/filter-class
  /filter

  !-- This filter is used to convert the HTML generated by the WYSIWYG 
editor to wiki syntax --
  filter
filter-nameConversionFilter/filter-name

filter-classcom.xpn.xwiki.wysiwyg.server.filter.ConversionFilter/filter-class
  /filter

  !-- Filter used to 'steal' webdav requests made to the application 
root --
  filter
filter-nameDavFilter/filter-name
filter-classcom.xpn.xwiki.plugin.webdav.XWikiDavFilter/filter-class
  /filter

  !-- A filter that dispatches requests to the right action depending 
on the button pressed in the editing form. This
   is needed when javascript is disabled, since the browser cannot 
send the form data to different URLs depending on
   the button pressed. --
  filter
filter-nameActionDispatcher/filter-name
filter-classcom.xpn.xwiki.web.ActionFilter/filter-class
  /filter

  !-- The encoding filter MUST always be the first one, as setting the 
encoding does not work after accessing the request data. --
  filter-mapping
filter-nameSet Character Encoding/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherFORWARD/dispatcher
dispatcherERROR/dispatcher
  /filter-mapping

  filter-mapping
filter-nameRequestRestorer/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherFORWARD/dispatcher
  /filter-mapping

  filter-mapping
filter-nameConversionFilter/filter-name
servlet-nameaction/servlet-name
dispatcherREQUEST/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherFORWARD/dispatcher
  /filter-mapping

  filter-mapping
filter-nameDavFilter/filter-name
url-pattern/*/url-pattern
  /filter-mapping

  filter-mapping
filter-nameActionDispatcher/filter-name
url-pattern/*/url-pattern
  /filter-mapping

  !-- Initializes Plexus and puts a reference to the Plexus Component 
Manager in the Servlet
   Context. Also initializes the Container Manager component with 
the Servlet Context. --
  listener

listener-classorg.xwiki.container.servlet.XWikiPlexusServletContextListener/listener-class
  /listener

  !-- Main Plexus Servlet receiving all requests. For now this is 
mapped to some unused URL
   contex path since we're still using Struts but in the near 
future, Struts will go away
   and be replaced by XWiki's own Action component. --
  servlet
servlet-namePlexusServlet/servlet-name


Re: [xwiki-users] Problem deploying war file to Glassfish v2.1

2009-07-10 Thread Brett M. Bergquist
I wrote that bug :)  But I gave some incorrect information.  I said to 
set the schema as:

web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=...
version=2.4

Note that ...?   That is wrong and in the 1.9.1 release, Xwiki put in 
the correct schema locations.  But once that is done, then the web.xml 
does not validate.  There are a couple of problems in it that need to be 
fixed:

* The env-entry has the tags in the sequence env-entry-name,
  env-entry-value, env-entry-type, but they need to be in the
  sequence env-entry-name, env-entry-type, env-entry-value
* The servlet tags has their init-param tags listed in
  param-name, param-value, description order, but they need to be in
  description, param-name, param-value order
* The taglib tags need a jsp-config tag wrapped around these as
  per the 2.4 spec


AjdinBrandic wrote:
 I got it to work using this fixed bug solution
 http://jira.xwiki.org/jira/browse/XWIKI-3985

 Ajdin


 Willi Schiegel wrote:
   
 Hello All!

 I want to deploy the xwiki-enterprise-web-1.9.1.war file into a
 Glassfish v2.1 server under Solaris 10 Update 7. The deployment does not
 work. Here is the error message:

 Deploying application in domain failed; Error loading deployment
 descriptors for module [xwiki] Line 170 Column 20 -- Deployment
 descriptor file WEB-INF/web.xml in archive [xwiki].
 cvc-complex-type.2.4.d: Invalid content was found starting with element
 'description'. No child element is expected at this point.

 Does someone know how I can fix this?

 Thank you very much.

 Greetings,
 Willi
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users


 

 --
 View this message in context: 
 http://n2.nabble.com/Problem-deploying-war-file-to-Glassfish-v2.1-tp3203311p3236545.html
 Sent from the XWiki- Users mailing list archive at Nabble.com.
 ___
 users mailing list
 users@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/users


   

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users