phpwiki-talk

[Phpwiki-talk] Notification preferences storage ??!!??

[Sabri L. <sab...@st...>]

Hi all,

I have some questions related to monitoring preferences storage and user =
pages that phpwiki creates if a user sets some preferences. It will be =
great if someone could provide some explanations on the subject.

First I want to know how monitoring data is stored in Phpwkii when users =
and preferences are stored in wiki pages?

I found the monitoring data in pref table and in 'global_data' wiki page =
!
Then, I want to know where phpwiki find the monitoring data after a page =
change for example.

Then is it possible to remove a monitoring data from 'global_data' page =
?

If I rename a user then his monitoring data will not change and the =
notification emails keep sent to the old user adress. So, what is the =
procedure for user rename without altering monitoring data.

Any help will be too much appreciated.

Thanks,
-- Sabri.

Re: [Phpwiki-talk] LDAP Config (Correction)

[Frank P. L. <fr...@th...>]

I changed LDAP_SEARCH_FIELD to uid and now do not get the  
(nosuchuser) tag in the debug message:

DEBUG: ALLOW_ANON_EDIT = false, ALLOW_BOGO_LOGIN = false,  
ALLOW_USER_PASSWORDS = true, ENABLE_PAGEPERM = true, USER_AUTH_ORDER:  
=> LDAP => Forbidden, USER_AUTH_POLICY: first-only,  
PASSWORD_LENGTH_MINIMUM: 0

Still a little confounded.  Been trying to get slapd to push out its  
debug messages on the LDAP server, in case it's my end.  Again, any  
ideas would be helpful.  I'm slowly making (some) progress (I think).

--Frank



On Apr 19, 2007, at 1:00 PM, Leef wrote:

>
> Hi Folks, I've been looking and trying several different Wikis to  
> use in
> conjunction with.  I finally settled on phpWiki a week ago - so I'm  
> pretty
> much a noob at phpwiki.
>
> I am trying to get it to authenticate against our LDAP server.  (an  
> OsX
> Tiger server (10.4.8) running Open Directory)
>
> It would seem that have successfully been able to bind to the LDAP  
> server
> however I am now getting new debug messages above.  I've read  
> through the
> talks in the forum online and they've been very helpful getting me  
> this far
> but now I'm lost.
>
> DEBUG: ALLOW_ANON_EDIT = false, ALLOW_BOGO_LOGIN = false,
> ALLOW_USER_PASSWORDS = true, ENABLE_PAGEPERM = true,  
> USER_AUTH_ORDER: =>
> LDAP (nosuchuser) => Forbidden, USER_AUTH_POLICY: first-only,
> PASSWORD_LENGTH_MINIMUM: 0
>
> Any thoughts or ideas?  Perhaps I have overlooked something small?
> Thank you in advance.
>
> --Frank
>
>
> config.ini
> USER_AUTH_ORDER = LDAP
> USER_AUTH_POLICY = first-only
> ;ENABLE_USER_NEW = false
> ;ENABLE_PAGEPERM = false
>
> LDAP_AUTH_HOST = "ldap://10.10.1.10"
> LDAP_BASE_DN = "cn=users,dc=Name,dc=local"
> LDAP_SET_OPTION = "LDAP_OPT_PROTOCOL_VERSION=3:LDAP_OPT_REFERRALS=0"
> LDAP_AUTH_USER = "uid=root,cn=users,dc=Name,dc=local"
> LDAP_AUTH_PASSWORD = somePassHere
> LDAP_SEARCH_FIELD = memberUID
> ;LDAP_OU_USERS = ou=Users
> ;LDAP_OU_GROUP = ou=Groups
>
>
> -- 
> View this message in context: http://www.nabble.com/LDAP-Config- 
> tf3608405.html#a10082231
> Sent from the phpwiki-talk mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] LDAP Config

[Leef <fr...@th...>]

Hi Folks, I've been looking and trying several different Wikis to use in
conjunction with.  I finally settled on phpWiki a week ago - so I'm pretty
much a noob at phpwiki.

I am trying to get it to authenticate against our LDAP server.  (an OsX
Tiger server (10.4.8) running Open Directory) 

It would seem that have successfully been able to bind to the LDAP server
however I am now getting new debug messages above.  I've read through the
talks in the forum online and they've been very helpful getting me this far
but now I'm lost.

DEBUG: ALLOW_ANON_EDIT = false, ALLOW_BOGO_LOGIN = false,
ALLOW_USER_PASSWORDS = true, ENABLE_PAGEPERM = true, USER_AUTH_ORDER: =>
LDAP (nosuchuser) => Forbidden, USER_AUTH_POLICY: first-only,
PASSWORD_LENGTH_MINIMUM: 0

Any thoughts or ideas?  Perhaps I have overlooked something small?  
Thank you in advance.

--Frank


config.ini
USER_AUTH_ORDER = LDAP
USER_AUTH_POLICY = first-only
;ENABLE_USER_NEW = false
;ENABLE_PAGEPERM = false

LDAP_AUTH_HOST = "ldap://10.10.1.10"
LDAP_BASE_DN = "cn=users,dc=Name,dc=local"
LDAP_SET_OPTION = "LDAP_OPT_PROTOCOL_VERSION=3:LDAP_OPT_REFERRALS=0"
LDAP_AUTH_USER = "uid=root,cn=users,dc=Name,dc=local"
LDAP_AUTH_PASSWORD = somePassHere
LDAP_SEARCH_FIELD = memberUID
;LDAP_OU_USERS = ou=Users
;LDAP_OU_GROUP = ou=Groups


-- 
View this message in context: http://www.nabble.com/LDAP-Config-tf3608405.html#a10082231
Sent from the phpwiki-talk mailing list archive at Nabble.com.

[Phpwiki-talk] Fwd: Critical phpwiki c99shell exploit

[Reini U. <ru...@x-...>]

VGhpcyBidWd0cmFxIGFuc3dlciBzaG93cyBhIGxpbmsgdG8gYSBzY3JlZW4gc2hvdCBvZiB0aGUg
Yzk5IHNoZWxsLgoKICBodHRwOi8vd3d3LmhvbmV5bmV0Lm9yZy9wYXBlcnMvd2ViYXBwLwoKU28g
cGhwMywgcGhwNCBhbmQgcGhwNSBzaG91bGQgYmUgYmxvY2tlZCBub3cuCgpCdXQgdW50aWwgZnVy
dGhlciBhbmFseXNpcyBJIHdvdWxkIGNvbXBsZXRlbHkgZGlzYWJsZSB0aGUgVXBMb2FkIHBsdWdp
biBmb3IKdW5zZWN1cmUgdXNlcnMuCgotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0t
LS0tLS0KRnJvbTogSmFtaWUgUmlkZW4gPGphbWllLnJpZGVuQGdtYWlsLmNvbT4KRGF0ZTogMTIu
MDQuMjAwNyAxODo1OQpTdWJqZWN0OiBSZTogQ3JpdGljYWwgcGhwd2lraSBjOTlzaGVsbCBleHBs
b2l0ClRvOiBidWd0cmFxQHNlY3VyaXR5Zm9jdXMuY29tLCAicnVyYmFuQHgtcmF5LmF0IiA8cnVy
YmFuQHgtcmF5LmF0PgoKCk9uIDEyIEFwciAyMDA3IDEzOjE0OjE0IC0wMDAwLCBydXJiYW5AeC1y
YXkuYXQgPHJ1cmJhbkB4LXJheS5hdD4gd3JvdGU6Cj4gVmlhIHRoZSBQaHB3aWtpIDEuMy54IFVw
TG9hZCBmZWF0dXJlIHNvbWUgaGFja2VycyBmcm9tIHJ1c3NpYSB1cGxvYWRlZCBhIHBocDMgb3Ig
cGhwNCBmaWxlLAo+IGluc3RhbGwgYSBiYWNrZG9vciBhdCBwb3J0IDgwODEgYW5kIGhhdmUgYWNj
ZXNzIHRvIHlvdXIgd2hvbGUgZGlzYyBhbmQgb3ZlcnRha2UgdGhlIHNlcnZlci4KPgo+IEEgdXJs
IGluIHRoZSBmaWxlIGlzIGh0dHA6Ly9jY3RlYW0ucnUvcmVsZWFzZXMvYzk5c2hlbGwKPgo+IFRo
ZSB1cGxvYWRlZCBmaWxlIGhhcyBhIHBocCwgcGhwMyBvciBwaHA0IGV4dGVuc2lvbiBhbmQgbG9v
a3MgbGlrZSBhIGdpZiB0byB0aGUgbWltZSBtYWdpYy4KPiBTbyBhcGFjaGUgdXN1YWxseSBhY2Nl
cHRzIGl0Lgo+Cj4gVG8gZml4IHRoaXMgcGhwd2lraSBpc3N1ZSBhdCBmaXJzdCBtb3ZlIHRoZSBs
aWIvcGx1Z2luL1VwTG9hZC5waHAgZmlsZSBvdXQgb2YgdGhpcyBkaXJlY3RvcnkuCj4KPiBZb3Ug
Y2FuIGZpeCBpdCBieSBhZGRpbmcgdGhvc2UgdHdvIGxpbmVzIHRvIHlvdXIgbGlzdCBvZiBkaXNh
bGxvd2VkIGV4dGVuc2lvbnM6Cj4gICBwaHAzCj4gICBwaHA0Cj4gQ3VycmVudGx5IG9ubHkgInBo
cCIgaXMgZGlzYWxsb3dlZC4KClNvbWUgcGVvcGxlIGFsc28gbWFwIC5waHA1IC0gZ29vZ2xlIGZv
ciAiQWRkVHlwZQphcHBsaWNhdGlvbi94LWh0dHBkLXBocDUgLnBocDUiIGFuZCAiQWRkVHlwZSBh
cHBsaWNhdGlvbi94LWh0dHBkLXBocAoucGhwNSIgLSBhbmQgZ29vZG5lc3Mga25vd3Mgd2hhdCBl
bHNlLgoKVGhpcyB3b3VsZCBiZSBtdWNoIGJldHRlciByZS13cml0dGVuIHRvIHVzZSBrbm93biBz
YWZlIGV4dGVuc2lvbnMsIG9yCnRoZSBhZG1pbiBuZWVkcyB0byBjYXJlZnVsbHkgY29tcGFyZSB0
aGUgZGlzYWxsb3dlZCBsaXN0IGFnYWluc3QKaGlzL2hlciBodHRwZCBjb25maWcuCgooSWYgdGhl
cmUncyBhbnlvbmUgd2hvIGRvZXNuJ3Qga25vdyBjOTlzaGVsbCwgaXQncyBzb3J0IG9mIGEgaGVs
cGVyCmFwcCBmb3IgZG9pbmcgdGhpbmdzIG9uIHNlcnZlcnMgLSB0aGUga2luZCBvZiB0aGluZ3Mg
eW91IHByb2JhYmx5CmRvbid0IHdhbnQgZG9uZSAtIGFuZCBpcyBvZnRlbiB1c2VkIGluIGNvbmp1
bmN0aW9uIHdpdGggcmVtb3RlIGZpbGUKaW5jbHVkZSBhdHRhY2tzIHRvIGV4ZWN1dGUgc2hlbGwg
Y29tbWFuZHMuIFRoZXJlJ3MgYSBzY3JlZW5zaG90IGluCkFwcGVuZGl4IEIgYXQgaHR0cDovL3d3
dy5ob25leW5ldC5vcmcvcGFwZXJzL3dlYmFwcC8gLiAiRGVmYWNpbmcgVG9vbAoyLjAgYnkgcjN2
M25nNG5zIiBhbmQgcjU3c2hlbGwgYXJlIHNpbWlsYXIgdXRpbGl0aWVzIHlvdSBtYXkgaGF2ZSBj
b21lCmFjcm9zcy4pCgpjaGVlcnMsCiBKYW1pZQoKUFMuIEkgY2FuJ3Qgc2VlIHdoZXJlIGl0IGNo
ZWNrcyBpZiB0aGUgZmlsZSBpcyBhIEdJRiwgYnV0IGl0J3Mgbm90CmhhcmQgdG8gZm9vbCBzb21l
IHByb2dyYW1zLCBhbmQgSSBkb24ndCBsaWtlIHRoZSBpZGVhIG9mIGd1ZXNzaW5nIGZpbGUKdHlw
ZXMgYmFzZWQgb24gY29udGVudHMuIEl0J3Mgbm90IHNhZmUuCgo9PSBmb28ucGhwID09CkdJRjg5
YSFeQCJeQAo8P3BocAogIGVjaG8gImZvbyI7Cj8+Cj09PT09PT09PT09CgokIGZpbGUgZm9vLnBo
cApmb28ucGhwOiBHSUYgaW1hZ2UgZGF0YSwgdmVyc2lvbiA4OWEsIDMzIHggMzQKClRoZSBvdXRw
dXQgb2YgdmlzaXRpbmcgaHR0cDovL2xvY2FsaG9zdC9mb28ucGhwIHVuZGVyIGFwYWNoZSBpcwon
R0lGODlhIe+/vSLvv70gZm9vJy4KLS0KSmFtaWUgUmlkZW4gLyBqYW1lc3JAZXVyb3BlLmNvbSAv
IGphbWllQGhvbmV5bmV0Lm9yZy51awpVSyBIb25leW5ldCBQcm9qZWN0OiBodHRwOi8vd3d3LnVr
aG9uZXluZXQub3JnLwotLSAKUmVpbmkgVXJiYW4KaHR0cDovL3BocHdpa2kub3JnLyAgICAgICAg
ICAgICAgaHR0cDovL211cmJyZWFrLmF0LwpodHRwOi8vc3BhY2Vtb3ZpZS5tdXIuYXQvICAgaHR0
cDovL2hlbHNpbmtpLmF0Lwo=

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Harold H. <ha...@ha...>]

> 2007/4/12, Harold Hallikainen <ha...@ha...>:
>> > 2007/4/12, Sabri LABBENE <sab...@st...>:
>> >> Reini Urban wrote:
>> >> >Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload
>> a
>> >> >php3 or php4 file,
>> >> >install a backdoor at port 8081 and have access to your whole
>> >> >disc and overtake the server.
>> >> >
>> >> >See http://ccteam.ru/releases/c99shell
>> >>
>> >> I think that the URL is wrong.
>> >
>> > This url obviously worked in 2006. Now it is gone.
>> >
>> > I submitted a critical security alert to CERT and it will be in the
>> > cve reports of mitre.org
>> > also then (hopefully).
>>
>> As the one who was attacked, I can give you the IP addresses of the
>> attackers. Second, instead of disallowed extensions, I think it would be
>> much safet to have a list of ALLOWED extensions. I see this as a todo in
>> the upload plugin.
>
> Hm, I will think about it. Other opinions?
>
>> I have set my upload directory as read only and require users to now
>> email
>> me stuff to post.
>>
>> As to how much was visible to the hackers (and I have the code for their
>> script), it SEEMS that it would only be what user apache could see,
>> which
>> would be stuff it owns and stuff that is world readable. Is that
>> correct?
>
> Well not really. The c99shell script tries in various ways to get more
> access.
> At first it compiles and installs a backdoor at port 8081 and then
> with shell access it's normally quite easy for an experienced hacker
> to get root.
>
> --
> Reini Urban


THANKS for the support on this issue! I did an updatedb, then did locate
c99. The only stuff that comes up is this:

/usr/include/boost/numeric/interval/detail/c99sub_rounding_control.hpp
/usr/include/boost/numeric/interval/detail/c99_rounding_control.hpp
/usr/share/man/man1p/c99.1p.gz
/usr/bin/c99


In addition, port 8081 is blocked at the router (for incoming requests).
So, I'm hoping I'm ok!

I really think an approved filetype list for uploads would be nice. It
seems a lot easier than trying to anticipate everything bad that someone
will try.

THANKS for the support on this!

Harold

-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Reini U. <ru...@x-...>]

2007/4/12, Harold Hallikainen <ha...@ha...>:
> > 2007/4/12, Sabri LABBENE <sab...@st...>:
> >> Reini Urban wrote:
> >> >Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
> >> >php3 or php4 file,
> >> >install a backdoor at port 8081 and have access to your whole
> >> >disc and overtake the server.
> >> >
> >> >See http://ccteam.ru/releases/c99shell
> >>
> >> I think that the URL is wrong.
> >
> > This url obviously worked in 2006. Now it is gone.
> >
> > I submitted a critical security alert to CERT and it will be in the
> > cve reports of mitre.org
> > also then (hopefully).
>
> As the one who was attacked, I can give you the IP addresses of the
> attackers. Second, instead of disallowed extensions, I think it would be
> much safet to have a list of ALLOWED extensions. I see this as a todo in
> the upload plugin.

Hm, I will think about it. Other opinions?

> I have set my upload directory as read only and require users to now email
> me stuff to post.
>
> As to how much was visible to the hackers (and I have the code for their
> script), it SEEMS that it would only be what user apache could see, which
> would be stuff it owns and stuff that is world readable. Is that correct?

Well not really. The c99shell script tries in various ways to get more access.
At first it compiles and installs a backdoor at port 8081 and then
with shell access it's normally quite easy for an experienced hacker
to get root.

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Harold H. <ha...@ha...>]

> 2007/4/12, Sabri LABBENE <sab...@st...>:
>> Reini Urban wrote:
>> >Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
>> >php3 or php4 file,
>> >install a backdoor at port 8081 and have access to your whole
>> >disc and overtake the server.
>> >
>> >See http://ccteam.ru/releases/c99shell
>>
>> I think that the URL is wrong.
>
> This url obviously worked in 2006. Now it is gone.
>
> I submitted a critical security alert to CERT and it will be in the
> cve reports of mitre.org
> also then (hopefully).
> --
> Reini Urban
> http://phpwiki.org/              http://murbreak.at/
> http://spacemovie.mur.at/   http://helsinki.at/
>


As the one who was attacked, I can give you the IP addresses of the
attackers. Second, instead of disallowed extensions, I think it would be
much safet to have a list of ALLOWED extensions. I see this as a todo in
the upload plugin.

I have set my upload directory as read only and require users to now email
me stuff to post.

As to how much was visible to the hackers (and I have the code for their
script), it SEEMS that it would only be what user apache could see, which
would be stuff it owns and stuff that is world readable. Is that correct?

THANKS!

Harold

-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Reini U. <ru...@x-...>]

2007/4/12, Sabri LABBENE <sab...@st...>:
> Reini Urban wrote:
> >Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
> >php3 or php4 file,
> >install a backdoor at port 8081 and have access to your whole
> >disc and overtake the server.
> >
> >See http://ccteam.ru/releases/c99shell
>
> I think that the URL is wrong.

This url obviously worked in 2006. Now it is gone.

I submitted a critical security alert to CERT and it will be in the
cve reports of mitre.org
also then (hopefully).
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Sabri L. <sab...@st...>]

Reini Urban wrote:
>Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
>php3 or php4 file,
>install a backdoor at port 8081 and have access to your whole 
>disc and overtake the server.
>
>See http://ccteam.ru/releases/c99shell

I think that the URL is wrong.

>The uploaded file has a php, php3 or php4 extension and looks 
>like a gif to the mime magic.
>So apache usually accepts it.
>
>To fix this issue at first move the lib/plugin/UpLoad.php file 
>out of this directory.
>
>You can fix it by adding those two lines to your list of 
>disallowed extensions:
>
>php3
>php4
>
>Currently only php is disallowed.

Regards,
-- Sabri.

[Phpwiki-talk] IMPORTANT More UpLoad hacks

[Reini U. <ru...@x-...>]

Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
php3 or php4 file,
install a backdoor at port 8081 and have access to your whole disc and
overtake the server.

See http://ccteam.ru/releases/c99shell

The uploaded file has a php, php3 or php4 extension and looks like a
gif to the mime magic.
So apache usually accepts it.

To fix this issue at first move the lib/plugin/UpLoad.php file out of
this directory.

You can fix it by adding those two lines to your list of disallowed extensions:

php3
php4

Currently only php is disallowed.
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [Phpwiki-talk] Problem with SemanticRelations not saving/showing up

[Reini U. <ru...@x-...>]

2007/4/8, Walter Rafelsberger <wal...@gm...>:
> I'm testing phpwiki-1.3.13rc1 on a shared host and I'm having trouble
> getting SemanticRelations to work. I use DISABLE_UNITS = true.
>
> When I use
> <?plugin SemanticRelations page=* ?>
> I get a list with
> "Semantic relations for..."
> and
> "Attributes of ..."
> for every page. However, only the attributes for each page get listed,
>  the relations will not show up.
>
> When I try to save a page containing relations or attributes, the page
>  saves, but I get the following notic:
>
> Notice: "Undefined property: Cached_SemanticLink::$_attribute_base"

I fixed that in CVS.

> When I use the _BackendInfoPlugin on the page I can see that the
> attributes get saved but "get_relations('pagename')" doesn't show up.
> However, it's there in the "San Diego"-page which was set up with the
> virgin wiki.
>
> Any ideas?

No. Strange. Maybe try it with enclosing the definition into []

> PS: I'm playing around with PhpWiki's Semantic Web features and came
> up  with a mashup using MIT's SIMILE timeline, if you're interested,
> have a  look here:
> http://www.metaportaldermedienpolemik.net/blog/Blog/2007-04-07/wiki-SIMILE-timeline-mashup

This sounds like a nice idea for a RecentChange enhancement.
I'm just working on switching over to PageList for time-sorted lists,
such as rss, atom, ...
or RecentChanges, so this could make another nice format= directive.

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] Problem with SemanticRelations not saving/showing up

[Walter R. <wal...@gm...>]

Hi,

I'm testing phpwiki-1.3.13rc1 on a shared host and I'm having trouble
getting SemanticRelations to work. I use DISABLE_UNITS = true.

When I use
<?plugin SemanticRelations page=* ?>
I get a list with
"Semantic relations for..."
and
"Attributes of ..."
for every page. However, only the attributes for each page get listed,
 the relations will not show up.

When I try to save a page containing relations or attributes, the page
 saves, but I get the following notic:

Notice: "Undefined property: Cached_SemanticLink::$_attribute_base"

When I use the _BackendInfoPlugin on the page I can see that the
attributes get saved but "get_relations('pagename')" doesn't show up.
However, it's there in the "San Diego"-page which was set up with the
virgin wiki.

Any ideas?

Walter

PS: I'm playing around with PhpWiki's Semantic Web features and came
up  with a mashup using MIT's SIMILE timeline, if you're interested,
have a  look here:
http://www.metaportaldermedienpolemik.net/blog/Blog/2007-04-07/wiki-SIMILE-timeline-mashup

-- 
http://www.rafelsberger.at

[Phpwiki-talk] Important UpLoad security fix! was [Fwd: [phpwiki - Open Discussion] RE: upload security risk]

[Reini U. <ru...@x-...>]

Please all disable the UpLoad plugin or add the attached patch for an
important security fix.
Somebody is actually breaking in some wiki servers with uploading files
like "deface.php.3" which apache interestingly treats as php.

- if (preg_match("/(\." . join("|\.", $this->disallowed_extensions) .
")\$/",
+ if (preg_match("/(\." . join("|\.", $this->disallowed_extensions) .
")(\.|\$)/",

With this fix it goes:

"ERROR uploading 'passdecrypt.php.3':

Files with extension ad[ep], asd, ba[st], chm, cmd, com, cgi, cpl, crt,
dll, eml, exe, hlp, hta, in[fs], isp, jse?, lnk, md[betw], ms[cipt],
nws, ocx, ops, pcd, p[ir]f, php, pl, py, reg, sc[frt], sh[bsm]?, swf,
url, vb[esx]?, vxd, ws[cfh] are not allowed."


See https://sourceforge.net/forum/message.php?msg_id=4249177 and thanks 
to hhallikainen for reporting this after going through the pain for 
having a hacker abusing this.

Re: [Phpwiki-talk] About removing revisions from page history

[Sabri L. <sab...@st...>]

 

>-----Original Message-----
>From: php...@li... 
>[mailto:php...@li...] On Behalf 
>Of Reini Urban
>Sent: Thursday, April 05, 2007 3:17 PM
>To: Discussion on PhpWiki features, bugs, development.
>Subject: Re: [Phpwiki-talk] About removing revisions from page history
>
>Sabri LABBENE schrieb:
>> Hi,
>> 
>> After some tests, I think that changing expire params from 
>config.ini has no
>> effect. New values are not taken into consideration.
>> 
>> If this is true, expiring params are hard coded somewhere in 
>the code and I
>> can't figure out how to tune them so that phpwiki will store 
>all revisions.
>> 
>> I desasctivated the Archive cleanning from 'savePage()' function in
>> 'editpage.php' and Phpwiki continue to remove revisions 
>after each save.
>> 
>> I think that it is not a normal behaviour.
>> 
>> Any help/idea ? 
>> 
>> Cheers,
>> -- Sabri.
>> 
>> Sabri LABBENE (March 26, 2007 3:56 PM) wrote:
>>> Hi all,
>>> I noticed that phpwiki removes some revisions from a page 
>>> history. It removes either major and minor revisions.
>>> I want phpwiki to save all the revisions in the database. In 
>>> config.ini I commented these lines:
>>>
>>> ; Keep up to 8 major edits, but keep them no longer than a month.
>>> ;MAJOR_MAX_AGE = 32
>>> ;MAJOR_KEEP = 8
>>>
>>> ; Keep up to 4 minor edits, but keep them no longer than a week.
>>> ;MINOR_MAX_AGE = 7
>>> ;MINOR_KEEP = 4
>>>
>>> And uncomment these ones :
>>>
>>> ; Let all revisions be stored. Default since 1.3.11 
>>> MAJOR_MIN_KEEP = 2147483647 MINOR_MIN_KEEP = 2147483647
>
>Just to ensure: These should be in a seperate line. Like
>MAJOR_MIN_KEEP = 2147483647
>MINOR_MIN_KEEP = 2147483647

Yes. The layout and line breaks of my email were broken.

>>>
>>> That was not sufficient to make wiki store all revisions. It 
>>> kept the same behaviour and still removes some of the old revisions.
>>>
>

I finally found out how to tune these params.
It is from 'config-default.ini', thing I didn't expect.

Thanks,
-- Sabri.

Re: [Phpwiki-talk] About removing revisions from page history

[Reini U. <ru...@x-...>]

Sabri LABBENE schrieb:
> Hi,
> 
> After some tests, I think that changing expire params from config.ini has no
> effect. New values are not taken into consideration.
> 
> If this is true, expiring params are hard coded somewhere in the code and I
> can't figure out how to tune them so that phpwiki will store all revisions.
> 
> I desasctivated the Archive cleanning from 'savePage()' function in
> 'editpage.php' and Phpwiki continue to remove revisions after each save.
> 
> I think that it is not a normal behaviour.
> 
> Any help/idea ? 
> 
> Cheers,
> -- Sabri.
> 
> Sabri LABBENE (March 26, 2007 3:56 PM) wrote:
>> Hi all,
>> I noticed that phpwiki removes some revisions from a page 
>> history. It removes either major and minor revisions.
>> I want phpwiki to save all the revisions in the database. In 
>> config.ini I commented these lines:
>>
>> ; Keep up to 8 major edits, but keep them no longer than a month.
>> ;MAJOR_MAX_AGE = 32
>> ;MAJOR_KEEP = 8
>>
>> ; Keep up to 4 minor edits, but keep them no longer than a week.
>> ;MINOR_MAX_AGE = 7
>> ;MINOR_KEEP = 4
>>
>> And uncomment these ones :
>>
>> ; Let all revisions be stored. Default since 1.3.11 
>> MAJOR_MIN_KEEP = 2147483647 MINOR_MIN_KEEP = 2147483647

Just to ensure: These should be in a seperate line. Like
MAJOR_MIN_KEEP = 2147483647
MINOR_MIN_KEEP = 2147483647

>>
>> That was not sufficient to make wiki store all revisions. It 
>> kept the same behaviour and still removes some of the old revisions.
>>

Re: [Phpwiki-talk] About removing revisions from page history

[Sabri L. <sab...@st...>]

Hi,

After some tests, I think that changing expire params from config.ini has no
effect. New values are not taken into consideration.

If this is true, expiring params are hard coded somewhere in the code and I
can't figure out how to tune them so that phpwiki will store all revisions.

I desasctivated the Archive cleanning from 'savePage()' function in
'editpage.php' and Phpwiki continue to remove revisions after each save.

I think that it is not a normal behaviour.

Any help/idea ? 

Cheers,
-- Sabri.

Sabri LABBENE (March 26, 2007 3:56 PM) wrote:
>Hi all,
>I noticed that phpwiki removes some revisions from a page 
>history. It removes either major and minor revisions.
>I want phpwiki to save all the revisions in the database. In 
>config.ini I commented these lines:
>
>; Keep up to 8 major edits, but keep them no longer than a month.
>;MAJOR_MAX_AGE = 32
>;MAJOR_KEEP = 8
>
>; Keep up to 4 minor edits, but keep them no longer than a week.
>;MINOR_MAX_AGE = 7
>;MINOR_KEEP = 4
>
>And uncomment these ones :
>
>; Let all revisions be stored. Default since 1.3.11 
>MAJOR_MIN_KEEP = 2147483647 MINOR_MIN_KEEP = 2147483647
>
>That was not sufficient to make wiki store all revisions. It 
>kept the same behaviour and still removes some of the old revisions.
>
>Is there something else I should do ?
>
>Thanks,
>-- Sabri.
> 
>
>
>---------------------------------------------------------------
>----------
>Take Surveys. Earn Cash. Influence the Future of IT Join 
>SourceForge.net's Techsay panel and you'll get the chance to 
>share your opinions on IT & business topics through brief 
>surveys-and earn cash 
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&
>CID=DEVDEV
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

[Phpwiki-talk] Page caching problem, supposedly

[Tom E. <ro...@te...>]

Hi again,

I have always had the problem, that maybe 4 out of 5 requests
return ok, while one takes >20 seconds to complete, then
comes back without styles (i.e. plain HTML look).
(no other errors on the page, or in the apache log)

Since I re-did my whole install from SuSE 10.0 to 10.2
recently (new php, new apache, ...) - and I had this on the
old machine and have it on the new machine - this must be a
phpwiki or phpwiki config issue.
This is 1.3.12p3, but I've also had this on 1.3.11rc3 (maybe
also before that, can't remember). db=file.

While fixing the CalendarList, I made the observation
that in such cases, the page does not get execute (i.e. changes
to CalendarList.php not visible). Since I was reloading,
reloading, reloading the start page, it got worse and worse
until I got 5 subsequent failures on reload.

Now, when I added "?debug=1", it worked. Reload failed.
Changing "1" to "2" worked, but reload failed again, and so on.
Basically, by always increasing the debug level, I got no errors.
So this must have to do with page caching, right ?

Adding "nocache=1" or "nocache=purge" only seemed to
help once (each) !?

Setting "WIKIDB_NOCACHE_MARKUP = true" had no effect at all.
Is this setting still supported ?

I'd be happy to test out your debugging ideas, if you have
some.

Any ideas anyone ?

Cheers & Thanks,
Tom.

-- 
teicher.net - Guaranteed to be free of any useable content.

[Phpwiki-talk] CalendarList fixed

[Tom E. <ro...@te...>]

Hello,

I have now fixed the problems with CalendarList that I complained
about some weeks ago.
I am a Java Programmer and did this by "emulating php skills" though
copy/paste and google, so please review what I did. (Looks right
to me, though ;-)

Cheers, Tom.

-- 
teicher.net - Guaranteed to be free of any useable content.

Re: [Phpwiki-talk] upgrading: some problems

[Reini U. <ru...@x-...>]

Frank Van Damme schrieb:
> On 3/15/07, Matt Brown <ma...@ma...> wrote:
>> Hi Frank,
>>
>> I'm the Debian Maintainer for PHPwiki, so I'll see if I can help you out.
>>
>> On 3/15/07, Frank Van Damme < fra...@gm...> wrote:
>>> I have a phpwiki running. It's on version 1.3.4 and when I upgraded my
>>> distribution to Debian Etch lately, phpwiki stopped serving me wiki
>>> pages but opted for error messages instead. They probably have
>>> something to do with php being upgraded, but I'm not too concerned
>>> about *that*.
>> That's not very good. What version of the package were you upgrading from?
>> If you can send me some details about teh upgrade process, versions,
>> database backend, error messages, etc. I'll be happy to look into it and
>> make sure it's not a bug in the package. I have not had any other failed
>> upgrade reports recently.
> 
> Well, maybe I haven't been entirely clear about this, but my previous
> installation was not installed with a package. It was installed by
> extracting the projects zipfile/tarbal into /var/www/wiki and
> configuring a virtual host for it in Apache. The backend has always
> been MySQL. This is a home server I upgraded to Etch, and I just
> decided to install by package from now on. I admit it's probably quit
> a version jump.
> 
>>> That doesn't work for me. I get asked to sign in. I enter the values of
>>> ADMIN_USER and ADMIN_PASSWD in /etc/phpwiki/config.ini respectively.
>>> The result:
>>>
>>> Fatal Error:
>>> lib/WikiDB/backend/PearDB.php:1032: Error:
>>> WikiDB_backend_PearDB_mysql: fatal database error
>>> DB Error: no such table
>>> (SELECT prefs FROM pref WHERE userid='phpwiki' [nativecode=1146 **
>>> Table 'phpwiki.pref' doesn't exist])
>> Is this while trying to load upgrade.php?
>>  Cheers
> 
> This is what I get when loading /?action=upgrade .well, there is a
> sign-in page in between, where I get a similar error at the bottom.
> I'll include that one too:
> 
> lib/WikiDB/backend/PearDB.php:1032: Error:
> WikiDB_backend_PearDB_mysql: fatal database error
>  DB Error: no such table
>  (INSERT INTO accesslog
> (time_stamp,remote_host,remote_user,request_method,request_line,request_uri,request_args,request_time,status,bytes_sent,referer,agent,request_duration)
> VALUES(1174335080,'192.168.0.72','-','GET','GET /?action=upgrade
> HTTP/1.1','/?action=upgrade','action=upgrade','19/Mar/2007:21:11:20
> 0100',200,0,'','Mozilla/5.0 (compatible; Konqueror/3.5) KHTML/3.5.5
> (like Gecko)','8.97388792038') [nativecode=1146 ** Table
> 'phpwiki.accesslog' doesn't exist])
> 
> if I request /lib/upgrade.php the error is pretty similar:
> 
> Fatal Error:
> lib/WikiDB/backend/PearDB.php:1032: Error:
> WikiDB_backend_PearDB_mysql: fatal database error
>  DB Error: no such field
>  (SELECT cached_html FROM page WHERE pagename='lib/upgrade.php'
> [nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
> 
> Fatal PhpWiki Error
> lib/WikiDB/backend/PearDB.php:1032: Error:
> WikiDB_backend_PearDB_mysql: fatal database error
>  DB Error: no such field
>  (SELECT cached_html FROM page WHERE pagename='lib/upgrade.php'
> [nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
> DB Error: no such fieldDB Error: no such field

You have to upgrade your database structure.
Best done by exporting all your pages, running 
schemas/mysql-initialize.sql and importing all your pages again.

[Phpwiki-talk] About removing revisions from page history

[Sabri L. <sab...@st...>]

Hi all,
I noticed that phpwiki removes some revisions from a page history. It =
removes either major and minor revisions.
I want phpwiki to save all the revisions in the database. In config.ini =
I commented these lines:

; Keep up to 8 major edits, but keep them no longer than a month.
;MAJOR_MAX_AGE =3D 32
;MAJOR_KEEP =3D 8

; Keep up to 4 minor edits, but keep them no longer than a week.
;MINOR_MAX_AGE =3D 7
;MINOR_KEEP =3D 4

And uncomment these ones :

; Let all revisions be stored. Default since 1.3.11
MAJOR_MIN_KEEP =3D 2147483647
MINOR_MIN_KEEP =3D 2147483647

That was not sufficient to make wiki store all revisions. It kept the =
same behaviour and still removes some of the old revisions.

Is there something else I should do ?

Thanks,
-- Sabri.
=20

Re: [Phpwiki-talk] Problems with db4 files

[John S. <jst...@gm...>]

Thanks Reini,
That helped.
Cheers

Re: [Phpwiki-talk] Problems with db4 files

[Reini U. <ru...@x-...>]

2007/3/22, John Stevens <jst...@gm...>:
> Hi All,
> I have set up a nightly build using db4 files so I can test out Wysiwiki.  I
> am getting a whole lot of page spam that begins with:
>
> Fatal Error:
>
>
> lib/DbaDatabase.php:54 Error:
> dba_open(phpwikidb/session.db4): failed to open stream: No
> such file or directory
> file: phpwikidb/session.db4

try an absolute path for the DATABSE_DIRECTORY

> mode: c
> handler: db4 This is when opening a page in Wysiwiki and when trying to
> insert a table in wysiwyg mode.  The file is owned and rw by the httpd user,
> and contains data, so I am not so sure this is a permissions problem.  Has
> anyone seen this before?  I may have to make an oracle database for testing
> if thre are issues with DB4 (not allowed to use mysql).
> Cheers
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
>


-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] Problems with db4 files

[John S. <jst...@gm...>]

Hi All,
I have set up a nightly build using db4 files so I can test out Wysiwiki.  I
am getting a whole lot of page spam that begins with:

Fatal Error:

lib/DbaDatabase.php:54 Error: dba_open(phpwikidb/session.db4): failed to
open stream: No such file or directory

   - file: phpwikidb/session.db4
   - mode: c
   - handler: db4

 This is when opening a page in Wysiwiki and when trying to insert a table
in wysiwyg mode.  The file is owned and rw by the httpd user, and contains
data, so I am not so sure this is a permissions problem.  Has anyone seen
this before?  I may have to make an oracle database for testing if thre are
issues with DB4 (not allowed to use mysql).
Cheers

[Phpwiki-talk] Wiki page history shorten !

[Sabri L. <sab...@st...>]

Hi all,

For some pages, Phpwiki has truncated the page history. There are some =
revisions missing. Sometimes, even the first revision is not shown in =
the page history. I'll be pleased if someone have answers for these =
questions:

- Are the revision numbers incremental and consecutive for a given page =
?
- Could a major revision be based on a minor edit ?
- When accessing a page history, is there a possibility to have some =
revisions truncated ?

Thanks in advance,

-- Sabri.

Re: [Phpwiki-talk] upgrading: some problems

[Frank V. D. <fra...@gm...>]

On 3/15/07, Matt Brown <ma...@ma...> wrote:
> Hi Frank,
>
> I'm the Debian Maintainer for PHPwiki, so I'll see if I can help you out.
>
> On 3/15/07, Frank Van Damme < fra...@gm...> wrote:
> > I have a phpwiki running. It's on version 1.3.4 and when I upgraded my
> > distribution to Debian Etch lately, phpwiki stopped serving me wiki
> > pages but opted for error messages instead. They probably have
> > something to do with php being upgraded, but I'm not too concerned
> > about *that*.
>
> That's not very good. What version of the package were you upgrading from?
> If you can send me some details about teh upgrade process, versions,
> database backend, error messages, etc. I'll be happy to look into it and
> make sure it's not a bug in the package. I have not had any other failed
> upgrade reports recently.

Well, maybe I haven't been entirely clear about this, but my previous
installation was not installed with a package. It was installed by
extracting the projects zipfile/tarbal into /var/www/wiki and
configuring a virtual host for it in Apache. The backend has always
been MySQL. This is a home server I upgraded to Etch, and I just
decided to install by package from now on. I admit it's probably quit
a version jump.

> > That doesn't work for me. I get asked to sign in. I enter the values of
> > ADMIN_USER and ADMIN_PASSWD in /etc/phpwiki/config.ini respectively.
> > The result:
> >
> > Fatal Error:
> > lib/WikiDB/backend/PearDB.php:1032: Error:
> > WikiDB_backend_PearDB_mysql: fatal database error
> > DB Error: no such table
> > (SELECT prefs FROM pref WHERE userid='phpwiki' [nativecode=1146 **
> > Table 'phpwiki.pref' doesn't exist])
>
> Is this while trying to load upgrade.php?
>  Cheers

This is what I get when loading /?action=upgrade .well, there is a
sign-in page in between, where I get a similar error at the bottom.
I'll include that one too:

lib/WikiDB/backend/PearDB.php:1032: Error:
WikiDB_backend_PearDB_mysql: fatal database error
 DB Error: no such table
 (INSERT INTO accesslog
(time_stamp,remote_host,remote_user,request_method,request_line,request_uri,request_args,request_time,status,bytes_sent,referer,agent,request_duration)
VALUES(1174335080,'192.168.0.72','-','GET','GET /?action=upgrade
HTTP/1.1','/?action=upgrade','action=upgrade','19/Mar/2007:21:11:20
0100',200,0,'','Mozilla/5.0 (compatible; Konqueror/3.5) KHTML/3.5.5
(like Gecko)','8.97388792038') [nativecode=1146 ** Table
'phpwiki.accesslog' doesn't exist])

if I request /lib/upgrade.php the error is pretty similar:

Fatal Error:
lib/WikiDB/backend/PearDB.php:1032: Error:
WikiDB_backend_PearDB_mysql: fatal database error
 DB Error: no such field
 (SELECT cached_html FROM page WHERE pagename='lib/upgrade.php'
[nativecode=1054 ** Unknown column 'cached_html' in 'field list'])

Fatal PhpWiki Error
lib/WikiDB/backend/PearDB.php:1032: Error:
WikiDB_backend_PearDB_mysql: fatal database error
 DB Error: no such field
 (SELECT cached_html FROM page WHERE pagename='lib/upgrade.php'
[nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
DB Error: no such fieldDB Error: no such field

> --
> Matt Brown
> ma...@ma...
> Mob +64 21 611 544 www.mattb.net.nz

Thanks for wanting to help me out.

-- 
Frank Van Damme

This weekend, I've been mostly wearing geeky T-shirts.