Topic on Project:Support desk/Flow

When creating my first property in a newly downloaded semantic (forms 2.7) system running on a mostly new 1.23.1 wiki (wiki.afterworld.ru). i get the following error when hitting save or preview.

"This appears to be a cross-site request forgery; canceling save."

so i went around now totally understand whats happening with CSRF and why its there and all that. But for the life of me i can not figure out how to fix the problem. I havent edited my core mediawiki files but looking at the editpage.php i can see what i expect is correct to allow tokens. "var $mTokenOk = false;" I can;t figure out of the problem is a forms problem or a wiki problem, but i see the code in the forms code for the error.

My question is, what have i done, or not done, to cause this error. Any hint to lead me in the right direction would be great. Thanks! --Dale>

I was just involved in a discussion about CSRF and SemanticForms and Yaron said he took care of this in the latest version.

Maybe you can help us figure out how you are getting this?

If latest version is 1.23.3 i have that ready to upgrade, but old time IT guy like me doesn't upgrade during a problem unless its a known fix. Shall I wait for Yaron here or open up a discussion on his page? Thanks!

I was hoping he would respond to the mention of his name here (I think that is part of Echo), but he didn't.

You appear to be running the latest version of SemanticForms, so I don't think upgrading would help.

I've sent him an email asking him to come look at this.

A start would be to tell us what is giving you that message: What browser are you using? Any browser extensions?

A well IE 11.09 Chrome 37 both produced the same error. Also has done it on 3 machines with none of the same extensions installed on different versions of IE. So i eliminated the browser as the default problem. Do note that i'm machines live in a Active Directory Domain, which always could cause some sort of limitation that is hidden.

When i run the create a category page i get no such error and successfully created a category. I have not run a Create a Class or templateyet because i simply haven't gotten to that stage (I am learning all this semantic stuff this week)

Note i did get a person to try it with a non-domain'ed machine in Chrome 37 and they got the same error (With my account). Which gives me the idea to try another account... will ask another admin to try.

http://wiki.afterworld.ru/index.php?title=Special:CreateProperty is the page with the problem.

Confirmed another admin level user had same problem.

Hi - that's too bad.

I should note that Echo didn't notify me! I don't know if it was supposed to. But Mark emailed me about this.

Also, there was actually no change to CSRF stuff in the latest version; the CSRF checking was all added in version 2.6.1, which was released 8 months ago; so I don't think there's a general bug in SF related to this.

Rather, I'm guessing that it's something server-side on the wiki, though I don't know what that is. Perhaps indeed it's the use of Active Directory; I don't know much about all that stuff, unfortunately.

Got the same problem, turned off visual editor and ldapauth. Still getting the error.

disabled dynamic page list (third party) .... now it saves

Im not using dynamic page list. I am using dynamic sidebar, i will try turning that off. I noted above that i proved it had nothing to do with active directory. It has to be something with the wiki that it causing it i agree. Now how do i determine what it is? I only have FTp access to my wiki, no cpanel or SSH.

I disabled DynamicSidebar and it worked. so there is a fight going on with the dynamic sidebar and dynamic page list.

dynamic page list (mediawiki) is working for me... now having a look it the reduzed feature set will work on our wiki

I have experienced the same problem. I get message "This appears to be a cross-site request forgery; canceling save" when hitting save or preview. However if I disable Extension:ShortUrl everything works fine.

Mediawiki 1.23.5.

I have the same issue ... I run a BlueSpice MW (2.23) on MediaWiki (1.23.7) with SMW 2.0 and I am unable to add attributes. In fact, the entire attribut thing appears to be broken:

    NO_VALID_VALUE mit Datentyp Text (0 Vorkommen)
    NO_VALID_VALUE mit Datentyp Zahl (0 Vorkommen)
    NO_VALID_VALUE mit Datentyp Quellcode (0 Vorkommen)
    NO_VALID_VALUE mit Datentyp Zahl (0 Vorkommen)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE mit Datentyp Datum (0 Vorkommen)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE mit Datentyp Wahrheitswert (0 Vorkommen)
    NO_VALID_VALUE mit Datentyp Seite (0 Vorkommen)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE (0)
    NO_VALID_VALUE mit Datentyp Datum (0 Vorkommen)

That looks quite strange

I tried fixing it through the SMW admin desk and an update in the terminal but to no avail. I try a second attempt in a VM with MW on 1.24.

Same Probleme here with BlueSpice 2.23, mediawiki 1.23.7 SemanticForms 3.1 (1b189e3). When i try to define a new propertie got this error : This appears to be a cross-site request forgery; canceling save.

I found the source and a bypass to the problem. When Bluespice extension "WikiAdmin" is activated, it seams to remove the namespace created by the Semantic MediaWiki extention, to be more precise, the Property, Type and Concept Namespace (and there "talk" ones). So when Forms try to add something to a namespace that no longer exist, it give the cross-site request forgery. The bypass I found is not "by the book", but it works. Just create the namespaces somewhere else, I put them in the LocalSettings.php by adding these lines:

$wgExtraNamespaces[102] = "Property";
$wgExtraNamespaces[103] = "Property_talk";
$wgExtraNamespaces[104] = "Type";
$wgExtraNamespaces[105] = "Type_talk";
$wgExtraNamespaces[108] = "Concept";
$wgExtraNamespaces[109] = "Concept_talk";

Hope it helps!

I found the source and a bypass to the problem. When Bluespice extension "WikiAdmin" is activated, it seams to remove the namespace created by the Semantic MediaWiki extention, to be more precise, the Property, Type and Concept Namespace (and there "talk" ones). So when Forms try to add something to a namespace that no longer exist, it give the cross-site request forgery. The bypass I found is not "by the book", but it works. Just create the namespaces somewhere else, I put them in the LocalSettings.php by adding these lines:

$wgExtraNamespaces[102] = "Property";
$wgExtraNamespaces[103] = "Property_talk";
$wgExtraNamespaces[104] = "Type";
$wgExtraNamespaces[105] = "Type_talk";
$wgExtraNamespaces[108] = "Concept";
$wgExtraNamespaces[109] = "Concept_talk";

Hope it helps!

Yes, it does ... curiously enough, it does not work with the language settings on "en", to whcih I had switched to in order to do some bugtracking with phpunit, but once I changed back to de and disabled my own namespace additions, it worked. Yet, I cannot say that I fully understand why. Nevertheless, thanks a lot ...

Adding these extra namespaces did solve the problem for me on a MW 1.26.3,/ SMW 2.3.1 installation.

I don't have the Bluespice extension installed and Dynamic Page List running.

Language setting doesn't seem to have any effect.

Yes for me too thanks!.. after trying a number of other work arounds, your solution worked on a clean install of MediaWiki/Bluespice and Semantic Mediawili.

Sorry to say that, but I just installed the latest version of MediaWiki, and I run into the same problem. Unfortunately I do not use any of the extensions described on this page and none of the solutions mentioned worked for me. There still seems to be a bug in the code.

Correction: The $wgExtraNamespaces-lines DID correct the problem. But it might be interesting for you to know that I do not use the extension "WikiAdmin" so this extension can not be the cause of the problem.

Had the same problem with a brand new MW 1.26.2 and SF 3.4.1 (fe2648a).

I could fix it by changing the value at which the SMW namespaces start.

I used $smwgNamespaceIndex = 108;

Same problem when saving a class.

MW: 1.26.2

SMW: 2.3.1

SF: 3.6-alpha (e827e19)

It's running on localhost for what it's worth.

Just a note: for those encountering this after installing SMW/SF with Composer, don't forget that you still need to add enableSemantic('yourdomain.com') in your LocalSettings. Without it, you will get this error.

Thanks for the pointer. There's a slight typo in your post. The correct syntax is enableSemantics( 'example.org' ); - with an "s", see https://www.semantic-mediawiki.org/wiki/Help:Installation/Troubleshooting