Error and response with 405 code when try to deploy node

I also followed the instructions for installing and configuring the deployment module and am getting the same errors. It seems that Services 7.x-3.4 implemented a CSRF security bug fix for SA-CONTRIB-2013-051 and the deployment client is not passing the X-CSRF-Token header.

Working on a patch. Will post when I get it.

I've rolled a patch against the 7.x-2.x branch of the deployment module. As long as you aren't sending files, everything works. (Files is a separate issue with UUID.)

What version of the Services module are you using? And is your service configured to use session authentication? I tested the Deploy module using Services 7.x-3.4 since that is where the X-CSRF-Token header was added.

The patch works for my issue (a little different error message, but still CSRF issue). My error message was:
WD deploy: DeployServiceException: Service error: 401 Unauthorized: CSRF validation failed in
DeployServiceRest->httpRequest() (line 70 of [redacted]/sites/all/modules/deploy/includes/DeployServiceRest.inc).

I applied this patch to deploy-7.x-2.0-alpha1.

Thank you!

Glad this worked for you paul. Hopefully the module maintainers will roll it in.

I ran into a situation locally where this patch didn't work because the port wasn't included in the token request. I've tweaked the patch to accomodate a port if it's there.

One more modification, the x-csrf-token needs to be sent on logout as well.

#8 works great

#8 worked. Thanks for the catch on the port...i didn't even think about it.

I will look at merging this in the coming days.

Committed to 7.x-2.x-dev. I'll probably roll a new release later today.

Thanks!

That's a great fix and it works for me too, but it doesn't solve the original poster's problem. Instead, it solved #2020027: Services 3.4 has changed REST parameters and Session Authentication breaking Deploy.

Hey Rob, I think OP and I had the same issue.

Hi diwant. You'll have to take it up with him because I didn't have that issue. I found it from a keyword search but was really looking for that other issue. Can't help, sorry.

Edit: Upon reading this again, it sounded rude. Sorry diwant, but I didn't recognize you name and so didn't realize that you were the one who filed that other issue. I had the context of your comment all wrong.

Guys,

This does not take into account any Basic Authentication that might be set up on the target for deploy.
The patch I include works on 7.x-2.x.

+++ b/plugins/DeployAuthenticatorSession.incundefined
@@ -63,10 +63,20 @@ class DeployAuthenticatorSession implements DeployAuthenticator {
+          $pass = ':'. $parts['pass'];
...
+        $token_url = $parts['scheme'] . '://' . ($user ? $user . $pass . '@' : '') . $parts['host'] . $port . '/services/session/token';

can we move the ':' to the token_url line, I had to read this three times to find out the ':' is part of $pass

Ah,

I did it like that because I thought it'd be possible to only provide a username without a password... so only when the password is there, the ':' should be included.

Looks better

Looking quickly at the code I don't event know why we split apart the url and then assemble it again, right after. It feels something like this would be enough:

$token_url = trim($this->service->config['url'], '/') . '/services/session/token';

But, I've committed #20 since it works, and solved the problem. Optimizations can be tested and committed later. I don't have time for that right now :-)

I applied the patch in #20, but still get the error:

DeployAuthenticationException: Authentication error: 404 Failed to retrieve CSRF token. in DeployAuthenticatorSession->deploy() (line 73 of /opt/labs/sites/all/modules/deploy/plugins/DeployAuthenticatorSession.inc).

I use 7.x-2.0-alpha2, and services is 3.5.

Is there any workarround to get my content published?

The construction of $token_url does not deal with endpoint URLs such as http://example.com/drupal/api: Additional path elements in the targets base url are skipped.

The following worked for me:

        // We suppose that the endpoint URL adds just one path element to the
        // base URL of the target Drupal installation, so we strip this element.
        // TODO Is it possible to obtain the token URL from the service
        // endpoint itself?
        $truncated_endpoint_url = preg_replace('#(.*)/.*#', '$1', trim($this->service->config['url'], '/'));
        $token_url = $truncated_endpoint_url . '/services/session/token';

Can confirm I still get the error as well on latest dev and #25 doesn't resolve.

It seems the patch in 20 does work, must have been an incorrect setting I was using. As for $token_url not taking into account endpoint urls such as http://example.com/drupal/api. It definitely does when you look at how the $token_url is assembled:

$token_url = $parts['scheme'] . '://' . ($user ? $user . ':' . $pass . '@' : '') . $parts['host'] . $port . '/services/session/token';

It nevers uses $parts['path'] which corresponds to /drupal/api.

I am putting this back to fixed. I hope this is okay!

I'm still getting authentication errors with the latest -dev versions of deploy and services. When I set Services to use the 1.0 API for user login and logout on the endpoint (destination), I get "DeployAuthenticationException: Authentication error: 404 Failed to retrieve CSRF token" on the source site (when I run cron with a Queue API deployment processor or I deploy manually using a memory processor deployment processor).

When I set Services to use the 1.1 API for user login and logout on the endpoint (destination), I get "DeployAuthenticationException: Authentication error: 401 Unauthorized: Missing required argument name..."

services/session/token on the destination does return a token.

It looks like the 404 CSRF error (DeployAuthenticationException: Authentication error: 404 Failed to retrieve CSRF token. in DeployAuthenticatorSession->deploy() (line 88 of deploy/plugins/DeployAuthenticatorSession.inc) is due to the $token_url not being configured to work with a destination site that lives in a subdirectory. It is building $token_url as http://example.com/services/session/token instead of http://example.com/arbitrary/path/to/drupal/services/session/token.

I'll try to roll a patch.

Not sure that I love this, but it looks like the assumption of the services/rest path exists elsewhere, so I'm making the same assumption in stripping it out.

I've applied the patch in #31, but still having this problem. Also, my (test) sites aren't in sub-directories.

I'm new to using the Deploy module, I believe I've followed the steps shown here https://drupal.org/node/1406134 exactly. I've also tried using --dev on all the required modules, just in case. I tried more than once. No joy. :(

Is the deploy module known to be working right now, even using stock Drupal installs? Looks like a great module!

patch #31 worked for me

Hi Churel! Would you mind describing your configuration? I've tried with completely stock Drupal installs and I still get the problem after applying the patch.

Finally, go this working!

I was getting this error and looking in the code to find the problem, but in the end this was a problem with our web server configuration (in my case IIS 7/Fast CGI) not allowing the PUT verb. So, if you get this problem, do a search about allowing additional verbs for FastCGI (or ensure PUT verbs are allowed in whatever server you are using).

HTH someone!

#31 works :D

It looks like the token call on services is a action, not a operation. Actions on services should to be POST requests should they not?
I am also interested to know why the path is set to [api]/services/session/token. Should it not point to [api]/user/token?

I managed to get it authenticating after changing these, but I want to test some more. If I can spend some time on it soon I can put together a patch.

@chrinor2002 Can you upload a patch describing exactly what you did?

It's a bit strange because we're running the current setup in production on quite a few sites and its working fine. But I'm still interested in sorting this out...

Using the following modules on deploy source:
deploy-7.x-2.0-alpha2+26-dev
entity_dependency-7.x-1.0-alpha1+12-dev
services-7.x-3.7

Using the following on deploy target:
services-7.x-3.7

The patch assumed you would have also applied #31. Its totally possible I'm out to lunch on this :P I might try some fresh drush installs today to play around with the latest stables of everything for 7.x and see if I run into the same issues.

Although that was authenticating I was still getting a 401 on the PUT request. I assume thats a whole separate issue with my target server or install.

Alright! making some progress. I did a complete fresh install using drush for a source and for a target. When I attempted to run a simple deploy the following requests appeared in my access logs:

::1 - - [11/Jun/2014:09:56:12 -0600] "GET /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 200 11444
127.0.0.1 - - [11/Jun/2014:09:56:13 -0600] "POST /d7_tar/sync/user/login HTTP/1.0" 200 628
127.0.0.1 - - [11/Jun/2014:09:56:14 -0600] "GET /services/session/token HTTP/1.0" 404 220
::1 - - [11/Jun/2014:09:56:13 -0600] "POST /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 302 -

After changing to the dev version of deploy(and adding new dependencies):

::1 - - [11/Jun/2014:10:07:55 -0600] "GET /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 200 11444
127.0.0.1 - - [11/Jun/2014:10:07:57 -0600] "POST /d7_tar/sync/user/login HTTP/1.0" 200 637
127.0.0.1 - - [11/Jun/2014:10:07:57 -0600] "GET /services/session/token HTTP/1.0" 404 220
::1 - - [11/Jun/2014:10:07:57 -0600] "POST /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 302 -

After applying #31:

::1 - - [11/Jun/2014:10:11:11 -0600] "GET /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 200 11444
127.0.0.1 - - [11/Jun/2014:10:11:14 -0600] "POST /d7_tar/sync/user/login HTTP/1.0" 200 637
127.0.0.1 - - [11/Jun/2014:10:11:14 -0600] "GET /d7_tar/sync/services/session/token HTTP/1.0" 404 -
::1 - - [11/Jun/2014:10:11:14 -0600] "POST /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 302 -

After applying my code changes(I noticed my patch is broken, I just applied the lines manually):

:1 - - [11/Jun/2014:10:14:40 -0600] "GET /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 200 11444
127.0.0.1 - - [11/Jun/2014:10:14:42 -0600] "POST /d7_tar/sync/user/login HTTP/1.0" 200 637
127.0.0.1 - - [11/Jun/2014:10:14:43 -0600] "POST /d7_tar/sync/user/token HTTP/1.0" 200 55
127.0.0.1 - - [11/Jun/2014:10:14:43 -0600] "POST /d7_tar/sync/user/logout HTTP/1.0" 406 70
::1 - - [11/Jun/2014:10:14:42 -0600] "POST /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 302 -

After switching to entity_dependency-7.x-1.x-dev:

::1 - - [11/Jun/2014:12:58:51 -0600] "GET /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 200 11618
127.0.0.1 - - [11/Jun/2014:12:58:52 -0600] "POST /d7_tar/sync/user/login HTTP/1.0" 200 637
127.0.0.1 - - [11/Jun/2014:12:58:52 -0600] "POST /d7_tar/sync/user/token HTTP/1.0" 200 55
127.0.0.1 - - [11/Jun/2014:12:58:52 -0600] "PUT /d7_tar/sync/node/9f830421-fef2-4d28-8ab5-f3f294013a04.json HTTP/1.0" 401 26
::1 - - [11/Jun/2014:12:58:52 -0600] "POST /d7_src/admin/structure/deploy/plans/list/sync/deploy?cancel_path=admin/structure/deploy HTTP/1.1" 302 -

As it turns out the latest services returns the token with the initial login request. The services function _user_resource_login() has the following lines:

      $return = new stdClass();
      $return->sessid = session_id();
      $return->session_name = session_name();
      $return->token = drupal_get_token('services');

So its possible the block dealing with token data could just be removed, and the data from the original login (yay one less request!).

#31 works for me too! thanks

#31 works great

The error I had was

DeployAuthenticationException: Authentication error: 404 Failed to retrieve CSRF token. in DeployAuthenticatorSession->deploy() (line 94 of /Applications/MAMP/htdocs/drupal7/sites/all/modules/deploy/plugins/DeployAuthenticatorSession.inc).

Obviously running in a subdirectory. I did a test deployment with the patch and it worked successfully.

Setting as RTBC unless someone objects

I'm also seeing the error:

DeployAuthenticationException: Authentication error: 302 Failed to retrieve CSRF token.

This is with Deploy 7.x-2.0-alpha3 and Services 7.x-3.10

I've tested each of the above patches with no luck. I'm not running in a subdirectory. Any help is much appreciated.

i had to tell deploy to not follow redirects to get rid of 302 Failed to retrieve CSRF token. when the site i am deploying to has redirects

I've tried the patch from the issue mentioned in #48 and that didn't help either.

Could be a bit of a stretch but folks who are having trouble here may want to try out the patch at #2388119: Get CSRF token from /user/login endpoint. Please note that it would only make a difference if Services module 7.x-3.6 or newer is on the server (destination) side.

Sorry for 2 comments instead of 1…

Looking a bit closer, I think #2388119: Get CSRF token from /user/login endpoint actually means we don't need a patch in #31 (or the follow-up patch in #39) for sites hosted in subdirectories. There's a lot going on in this issue though so I may be missing something. I don't think RTBC is appropriate though…

#31 not works for me, any help plz

I'm with Cottser on this one. Please retest this with the latest HEAD from the 7.x-2.x branch which includes the patch from #2388119: Get CSRF token from /user/login endpoint. If the problem still exists reopen this issue.