2 Apr
2009
2 Apr
'09
2:07 p.m.
Hi Lilianne,
On Apr 2, 2009, at 1:29 PM, Lilianne E. Blaze wrote:
I'm probably not qualified but I thought this is what we did with
xwiki.org for example. I don't know the details of how we make it spam
proof but it's done with a stock xwiki install.
Vincent Massol wrote:
This is not a solution, it's a workaround. The dependency still
exists. You just moved it to be a runtime dependency instead of a
build time dependency.
See below.
On Apr 2, 2009, at 12:15 PM, Lilianne E. Blaze
wrote:
Yes, and the reason given was that it required hard dependency
mailsender -> core, which this patch doesn't have thanks to
reflection. Any chance of finally including mail auth
support?
I think we already discussed this in the past and the agreement was
to write a
sendmail component that would be used by the core and by the
sendmail plugin. Actually the mailsender plugin would no longer be
required and the new component could be exposed to velocity and used
directly by wiki pages instead of the mailsender plugin. There's
probably 2-3 days of work to do all this.
There's just one problem - it requires much more knowledge about XWiki
internals. As I already proved, I'm willing to contribute. But I'm not
willing to learn the whole system just to know where a dozen-line
patch
would best fit.
If someone can provide a patch that does this and respect xwiki's
coding conventions then it can be quickly applied.
The patch you have provided Lilianne is a workaround but not a good
long term solution. I don't know about the others but I'm personally
I agree, but I insist it's a must-have feature. One that should have
been included from 1.0. Better a crude but trivial workaround than
forcing users to set up a security hole / spam relay.
It can always be replaced later when someone comes up with something
better. Right now I seem to be the only one who cares.
wary of introducing too many hacks in xwiki's
code base. We've
I wouldn't call it a hack, it's just a trivial bridge replacing a
method
that's deprecated anyway. Hack implies lack of transparency, and that
code couldn't be easier to understand.
actually been doing the opposite for the past 2
years (removing hacks
and cleaning up code) so this would be a step backward IMO.
Please, take the issue a bit more seriously. As it is, there's no
way to
take a standard XWiki and make it spam-proof. Things like flexible
validation mails, captchas, bad words filters, spam ip filters, they
should be given very high priority, and they should work out-of-the-
box,
not treated as fluff.
Nobody is treating anything as "fluff". All I've heard so far on this
topic:
- yes this is something we are interested in implementing
- we've explained how a patch should be submitted several time for it.
You just said it's too complex for you to do using XWiki's coding best
practices. Fine.
You have several options:
1) try to convince people your issue is the most important one
compared to the existing ones (this is what you're doing here in this
mail and it's fair enough - apart from your mail's tone which I resent
but that's another story ;))
2) implement it yourself and submit a patch that can be applied
without spending 2 days on it (require to apply the xwiki best
practices)
3) pay someone to implement it (btw in case you're interested by this
you can contact http://xwiki.com - This is a good way to help sponsor
the dev of xwiki in the direction you want and it helps the project)
4) wait for a committer to have an itch to scratch in this domain.
Now let's cross finger and hope some committer have the time to work
on this soon enough for you.
Thanks
-Vincent
It's 2009, spammers, scammers, hackers, script
kiddies everywhere.
Put yourself in noob's shoes for a minute, try to set up a public-edit
wiki as a typical Joe "I just want it to work" User would, you'd be
ears-deep in spam as soon as it hit the google index.
And don't think mail auth has nothing to do with it - I'm willing to
bet
half a year's income that if you randomly choose 10 hosting
providers 7
of them will refuse to set up open relays, and 2 out of remaining 3
won't have any security at all.
Thanks
-Vincent
Greetings, Lilianne
>
>> Greetings, Lilianne
>>
>> Vincent Massol wrote:
>>> Hi devs,
>>>
>>> XE 1.8.1 is planned for the 6th of April (next Monday).
>>>
>>> I propose we plan a XE 1.8.2 two weeks after, i.e. for the 20th of
>>> April.
>>>
>>> The goals is that it'll contain the issues planned for 1.8.1 that
>>> are
>>> not finished:
>>> http://tinyurl.com/cpanfc
>>>
>>> Again the idea is to make rendering/wysiwyg bug fixes and
>>> improvements
>>> available to our users ASAP.
>>>
>>> Here's my +1
>>>
>>> Thanks
>>> -Vincent