JJ-OpusVL commented 10 years ago

Impacted versions

Saas-3 and Saas-5

Steps to reproduce

Set up an e-Commerce store with the Website Builder
Configure the PayPal payment acquirer
Place an order and make payment via PayPal
On the PayPal confirmation page, click the link "Return to the Merchant's site"
Current behaviour

Odoo returns HTTP error 405 - Method GET Not Allowed

Expected behaviour

Odoo order confirmation page should be displayed

JJ-OpusVL commented 10 years ago

An example URL giving the error is http://example.com/payment/paypal/dpn/

tde-banana-odoo commented 10 years ago

DPN seems working fine with 8.0. Could you check that your issues has been fixed meanwhile ?

AidenAndrews commented 10 years ago

Fresh install of Master trunk today. Throws same error as JJ-OpusVL mentioned. Any idea when the master branch will have this feature fixed? Today's date is 03/11/2014 for reference. Client sees error and invoice remains open and no payment registered.

tde-banana-odoo commented 10 years ago

Are you in mono-db or multi-db environnement, with or without db-filter ? Please give more details about your setup to ease reproducting the issue. Thanks !

Please note also that in master a field has been added on payment acquirers, auto confirmation, that allow to tune the way sale orders are confirmed. Please also note that in the current version of the ecommerce, the sale order can be confirmed, but no payment of invoices is done.

avmediadesign commented 10 years ago

I'm facing the same issue with Version 8.0-dcca9b5. Single db and no db-filter. Odoo returns HTTP error 405 - Method GET Not Allowed. Payment transaction is registered OK but sales order remains unpaid.

avmediadesign commented 10 years ago

Any news regarding this issue? Is this a known bug or Am I facing this problem because something is wrong at my end? Thanks for any help.

tmotyl commented 9 years ago

avmediadesign commented 9 years ago

Any news regarding the HTTP 405 error "Method GET Not Allowed" when returning from Paypal (via return to sore link)?

tmotyl commented 9 years ago

it works for me with newest v8 and also on saas.

morphace commented 9 years ago

Is that issue fixed, or not? I'm having the same issue. In my case, need to return to a https:// URL. I'm using ecommerce, multi-db with db filter.

carlosospina commented 9 years ago

I run into the same issue with the latest code on the 8.0 branch on the date of my post, and figured how to solve it I realized two things.

1) The error only happened to me when I was logged in the system with and admin user. If I try to use a private browsing window I don't get the error.

2) The controller methods for DPN and IPN on the payment_paypal module are configured to only accept POST calls, hence the 405 error. If you remove the method (and the value) from the annotation on each controller, you don't get that error anymore, but I guess you'll detriment the security of the system

antwal commented 8 years ago

Hi, i have same issue with paypal sandbox test. I use latest version of 8.0 (2016 code) when I click like customer account on "Return to the Merchant's site" i receive this error. Thanks.

willmakenoise commented 8 years ago

I have the same issue. Using Odoo Enterprise 9.0

I've double and triple checked all PayPal settings (IPN, UTF-8, Redirect URL etc) and Payment Acquirer settings in Odoo. Tried with admin and normal user account. I have DB-filter on. No luck.

I find it frustrating that Odoo is advertising with PayPal integration when it doesn't work. The same goes for the Adyen Module. I've tried contacting support, but they do not reply. And I payed a pretty penny for the enterprise version...

lukebranch commented 8 years ago

@willmakenoise ,

I would suggest trying a payment in PayPal > Odoo in sandbox mode and make sure you have your debug logs switched on. Tail the debug logs and post the information in a gist on here (obviously hashing out any private information that the logs might contain).

The debug logs should provide you with more information for troubleshooting the issue and you should be able to see exactly where and how the IPN fails.

I'd also like to check, are you behind any reverse proxy (eg. Nginx), and what is your configuration?

willmakenoise commented 8 years ago

Thanks for your reply @lukebranch

I'll try that tonight. I'm behind nginx with this config:

upstream odoo {
        server 127.0.0.1:8069 weight=1 fail_timeout=3000s;
}

upstream odoo-im {
        server 127.0.0.1:8072 weight=1 fail_timeout=3000s;
}

server {
        listen 443;
        server_name odoo.server.com;

        access_log      /var/log/nginx/access.log;
        error_log       /var/log/nginx/error.log;

        ssl on;
        ssl_certificate /etc/nginx/ssl/server.crt;
        ssl_certificate_key /etc/nginx/ssl/server.key;
        keepalive_timeout       60;

        ssl_ciphers     HIGH:!ADH:!MD5;
        ssl_protocols   SSLv3 TLSv1;
        ssl_prefer_server_ciphers on;

        client_max_body_size 200m;

        proxy_buffers 16 64k;
        proxy_buffer_size 128k;

        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forward-For   $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forward-Proto https;

        location / {
                proxy_pass http://odoo;
                proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
                proxy_redirect off;
        }
        # cache some static data in memory for 60 mins.
        location ~* ^/(openerp|openobject|web)/static/ {
                proxy_cache_valid 200 60m;
                proxy_buffering on;
                expires 864000;
                proxy_pass http://odoo;
        }
        location /longpolling/ {
                proxy_pass http://odoo-im;
        }
}
server {
        listen          80;
        server_name     odoo.nstgardermoen.no;
        add_header Strict-Transport-Security max-age=2592000;
        rewrite ^/.*$ https://$host$request_uri? permanent;
}

I did get the return redirect to work by modifying the payment_paypal module. In main.py I changed the _return_url variable from '/payment/paypal/dpn/' to '/shop/confirmation' This makes the return url work. The payment is registered in Odoo, but the sale order is not set to done, and no invoice is made. I'm confused about what Odoo will actually do at this point. Is it set up to make an invoice, or was this only available with a third party module in v8 (website_sale_autopay)?

willmakenoise commented 8 years ago

Here is the debug log from Odoo. Like @carlosospina said earlier, paypal requests a GET method, when Odoo only accepts a Post method. I have no idea what to do with that.

https://gist.github.com/willmakenoise/6585c4902121b8da1b8d

antwal commented 8 years ago

@willmakenoise

I have fixed it with:

Fix SSL certificates (buy it)
Check web.base.url on System Parameters, if you like me use SSL you need setup https:// on base.url with nginx reverse proxy

Thanks.

willmakenoise commented 8 years ago

@antwal

Thanks man! You saved the day! Much appreciated!

Edit: Turns out I forgot to reset the return_url in payment_paypal/controllers/main.py, so it seemed to work, but after resetting it, the error came back.

DidierLACOMBE commented 8 years ago

Hello I have juts installed Nginx with rev proxy but i have still same error method not allowed when coming back from Paypal (Server/payment/paypal/dpn)

antwal commented 8 years ago

@DidierLACOMBE See old messages for resolve the problem; if you continue to have problems; you must post the nginx configuration, the odoo version used and possible value of web.base.url

DidierLACOMBE commented 8 years ago

Hello the odoo version used is V9C community date : March 2015 (Odoo 9.0 - 20160325)

NGINX conf is

events { worker_connections 1024; }

http { upstream site.com { server 127.0.0.1:8073; }

access_log off;

 ########################################################################################
 # be careful Format is defined under HTTP block, but log directive is under server block
 # when forgotten, log format = default combined lay out !
 ########################################################################################

log_format  main2 '[$time_local] REQ: "$request" HOST: "$host" URI : "$uri" FORWARD: "$http_x_forwarded_for" HTTP REF: "$http_referer"';
proxy_connect_timeout 120s;

server {

# add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

listen      443 default;

server_name site.com www.site.com;

# access_log  /var/log/nginx/oddo.access.log;
# error_log   /var/log/nginx/oddo.error.log;
error_log  logs/error.log;
error_log  logs/error.log  notice;
error_log  logs/error.log  info;

ssl on;
ssl_certificate     site.crt;
ssl_certificate_key site.key;
keepalive_timeout   60;

ssl_ciphers             HIGH:!ADH:!MD5;
ssl_protocols           SSLv3 TLSv1;
ssl_prefer_server_ciphers on;

proxy_buffers 16 64k;
proxy_buffer_size 128k;
access_log  logs/access.log  main2;

location / {

    proxy_pass  http://site.com;
    access_log  logs/access.log  main2;
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
    proxy_redirect off;

    proxy_set_header    Host            $host;
    proxy_set_header    X-Real-IP       $remote_addr;
    proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Proto https;
           }

location ~* /web/static/ {

    access_log  logs/access.log  main2;
    proxy_cache_valid 200 60m;
    proxy_buffering on;
    expires 864000;
    proxy_pass http://site.com;
                          }
}

server {

listen      80;
server_name site.com www.site.com;
access_log  logs/access.log  main2;
error_log   logs/error_log.log;
rewrite_log on;
add_header Strict-Transport-Security max-age=2592000;
rewrite ^/.*$ https://$host$request_uri? permanent;
  }

}

DidierLACOMBE commented 8 years ago

Hello

the configuration for web.base.url is https:site.com

thanks for helping

willmakenoise commented 8 years ago

Have you configured your PayPal account?

Under "Website Payment Preferences" in your account, make sure to set:

Auto Return: On
Return URL: https://yourdomain.com/payment/paypal/ipn
Payment Data Transfer: Off

Other settings:

Make sure you have a trusted SSL Cert from a third party (not generated by you).
web.base.url should be https://yourdomain.com
You should also add web.base.url.freeze with value True to System Parameters. Without this the web.base.url tends to reset to a non SSL URL.

DidierLACOMBE commented 8 years ago

Hello

thanks for replying

yes paypal account has been configurated but I the return adress IS Https:yourdomain/payment/paypal/dpn (NOT / IPN) PDT is Off I have a trusted certificate (from rapid ssl) but I haven't set the web.basse.url.freeze SO I will give another try

Nginx conf is

events { worker_connections 1024; }

http { upstream mywebinar-openerp.com { server 127.0.0.1:8073; }

access_log off;

 ########################################################################################
 # be careful Format is defined under HTTP block, but log directive is under server block
 # when forgotten, log format = default combined lay out !
 ########################################################################################

log_format  main2 '[$time_local] REQ: "$request" HOST: "$host" URI : "$uri" FORWARD: "$http_x_forwarded_for" HTTP REF: "$http_referer"';
proxy_connect_timeout 120s;

server {

# add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

listen      443 default;

server_name mywebinar-openerp.com www.mywebinar-openerp.com;

# access_log  /var/log/nginx/oddo.access.log;
# error_log   /var/log/nginx/oddo.error.log;
error_log  logs/error.log;
error_log  logs/error.log  notice;
error_log  logs/error.log  info;

ssl on;
ssl_certificate     webinar-openerp.crt;
ssl_certificate_key webinar-openerp.key;
keepalive_timeout   60;

ssl_ciphers             HIGH:!ADH:!MD5;
ssl_protocols           SSLv3 TLSv1;
ssl_prefer_server_ciphers on;

proxy_buffers 16 64k;
proxy_buffer_size 128k;
access_log  logs/access.log  main2;

location / {

    proxy_pass  http://mywebinar-openerp.com;
    access_log  logs/access.log  main2;
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
    proxy_redirect off;

    proxy_set_header    Host            $host;
    proxy_set_header    X-Real-IP       $remote_addr;
    proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Proto https;
           }

location ~* /web/static/ {

    access_log  logs/access.log  main2;
    proxy_cache_valid 200 60m;
    proxy_buffering on;
    expires 864000;
    proxy_pass http://mywebinar-openerp.com;
                          }
}

server {

listen      80;
server_name mywebinar-openerp.com www.mywebinar-opener.com;
access_log  logs/access.log  main2;
error_log   logs/error_log.log;
rewrite_log on;
add_header Strict-Transport-Security max-age=2592000;
rewrite ^/.*$ https://$host$request_uri? permanent;
  }

}

DidierLACOMBE commented 8 years ago

see answer on GIT

thanks

Didier Lacombe

didier.lacombe303@gmail.com

Tél : 00 33 (0) 6 20 57 32 20 Fax : 00 33 (0) 4 78 42 11 58

2016-05-11 15:48 GMT+02:00 willmakenoise notifications@github.com:

Have you configured your PayPal account?

Under "Website Payment Preferences" in your account, make sure to set:

Auto Return: On

Return URL: https://yourdomain.com/payment/paypal/ipn

Payment Data Transfer: Off

Make sure you have a trusted SSL Cert from a third party (not generated by you).

web.base.url should be https://yourdomain.com

You should also add web.base.url.freeze with value True to System Parameters. Without this the web.base.url tends to reset to a non SSL URL.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/odoo/odoo/issues/766#issuecomment-218464074

DidierLACOMBE commented 8 years ago

web.base.url.freeze is not a standard parameter in ODOO 9 (not delivered with the test version)

so I have to create it

Isn't it ?

do you know where is defined all possible param for "system parameters"

thanks

Didier Lacombe

didier.lacombe303@gmail.com

Tél : 00 33 (0) 6 20 57 32 20 Fax : 00 33 (0) 4 78 42 11 58

2016-05-11 15:48 GMT+02:00 willmakenoise notifications@github.com:

Have you configured your PayPal account?

Under "Website Payment Preferences" in your account, make sure to set:

Auto Return: On

Return URL: https://yourdomain.com/payment/paypal/ipn

Payment Data Transfer: Off

Make sure you have a trusted SSL Cert from a third party (not generated by you).

web.base.url should be https://yourdomain.com

You should also add web.base.url.freeze with value True to System Parameters. Without this the web.base.url tends to reset to a non SSL URL.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/odoo/odoo/issues/766#issuecomment-218464074

DidierLACOMBE commented 8 years ago

hello

it's working now but we cheat a little bit since it's not /IPN that has to be called upon, but /DPN I will try with /DPN instead of / IPN

Thanks

Didier Lacombe

didier.lacombe303@gmail.com

Tél : 00 33 (0) 6 20 57 32 20 Fax : 00 33 (0) 4 78 42 11 58

2016-05-11 15:48 GMT+02:00 willmakenoise notifications@github.com:

Have you configured your PayPal account?

Under "Website Payment Preferences" in your account, make sure to set:

Auto Return: On

Return URL: https://yourdomain.com/payment/paypal/ipn

Payment Data Transfer: Off

Make sure you have a trusted SSL Cert from a third party (not generated by you).

web.base.url should be https://yourdomain.com

You should also add web.base.url.freeze with value True to System Parameters. Without this the web.base.url tends to reset to a non SSL URL.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/odoo/odoo/issues/766#issuecomment-218464074

DidierLACOMBE commented 8 years ago

Hello

Good news : IT works

under V9C community NGINX and PAYPAL SANDBOX

but it's not necessary to set the return adress into Paypal, I did the test with and without it, and it works well with no return adresses at all just set PID flag into the Acquirer configuration

In fact : PIB URL and RETURN URL are Hard Coded in ODOO Payment.paypal module, and I had a discussion with PAYPAL support confirming that when the RETURN URL is initialised, then the RETURN adress from Paypal account is not used

The critical feature in my case with the WEB.BASE.URL.FREEZE Flag,

the question is : where to find all this "hidden" parameters

thanks

Didier Lacombe

didier.lacombe303@gmail.com

Tél : 00 33 (0) 6 20 57 32 20 Fax : 00 33 (0) 4 78 42 11 58

2016-05-11 15:48 GMT+02:00 willmakenoise notifications@github.com:

Have you configured your PayPal account?

Under "Website Payment Preferences" in your account, make sure to set:

Auto Return: On

Return URL: https://yourdomain.com/payment/paypal/ipn

Payment Data Transfer: Off

Make sure you have a trusted SSL Cert from a third party (not generated by you).

web.base.url should be https://yourdomain.com

You should also add web.base.url.freeze with value True to System Parameters. Without this the web.base.url tends to reset to a non SSL URL.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/odoo/odoo/issues/766#issuecomment-218464074

a0c commented 8 years ago

According to PayPal:

rm Optional Return method. The FORM METHOD used to send data to the URL specified by the return variable.

Allowable values are:
0 — all shopping cart payments use the GET method
1 — the buyer's browser is redirected to the return URL by using the GET method, but no payment variables are included
2 — the buyer's browser is redirected to the return URL by using the POST method, and all payment variables are included
The default is 0.

So I think the PayPal form should send the rm=2 param as well, shouldn't it?

When I do so, I'm getting this:

2016-09-01 23:33:41,348 23947 INFO ema openerp.addons.payment_paypal.controllers.main: Beginning Paypal DPN form_feedback with post data {'address_city': ... 2016-09-01 23:33:41,907 23947 WARNING ema openerp.addons.payment_paypal.controllers.main: Paypal: answered INVALID on data verification 2016-09-01 23:33:41,909 23947 INFO ema werkzeug: 217.71.47.53 - - [01/Sep/2016 23:33:41] "POST /payment/paypal/dpn/ HTTP/1.0" 302 - 2016-09-01 23:33:42,277 23940 INFO ema werkzeug: 217.71.47.53 - - [01/Sep/2016 23:33:42] "GET /shop/payment/validate HTTP/1.0" 302 - ... 2016-09-01 23:33:45,564 23934 INFO ema werkzeug: 217.71.47.53 - - [01/Sep/2016 23:33:45] "GET /shop HTTP/1.0" 200 -

meaning that because of the INVALID verification I'm following the damned /shop/payment/validate => /shop route. And 7 seconds after the IPN arrives and confirms the SO + tx:

2016-09-01 23:33:48,459 23934 INFO ema openerp.addons.payment_paypal.controllers.main: Beginning Paypal IPN form_feedback with post data {'address_city': 2016-09-01 23:33:49,032 23934 INFO ema openerp.addons.payment_paypal.controllers.main: Paypal: validated data 2016-09-01 23:33:49,034 23934 INFO ema openerp.addons.payment_paypal.models.paypal: Received a notification from Paypal with IPN version 3.8 2016-09-01 23:33:49,039 23934 INFO ema openerp.addons.payment_paypal.models.paypal: Validated Paypal payment for tx SO00707: set as done 2016-09-01 23:33:49,064 23934 INFO ema openerp.addons.website_sale.models.payment: transaction processed: tx ref:SO00707, tx amount: 0.1 2016-09-01 23:33:49,066 23934 INFO ema openerp.addons.website_sale.models.payment: transaction completed, confirming order SO00707 (ID 707)

Sometimes however PayPal provides an old interface visually split in 2 parts (left + right). In this case POST data happen to contain the address_city provided by me in Odoo form, not the one of the PayPal user I use to pay the SO. Then the DPN succeeds:

2016-09-01 22:07:35,888 20222 INFO ema openerp.addons.payment_paypal.controllers.main: Beginning Paypal DPN form_feedback with post data {'address_city': 2016-09-01 22:07:36,955 20222 INFO ema openerp.addons.payment_paypal.controllers.main: Paypal: validated data 2016-09-01 22:07:36,956 20222 INFO ema openerp.addons.payment_paypal.models.paypal: Received a notification from Paypal with IPN version 3.8 2016-09-01 22:07:36,960 20222 INFO ema openerp.addons.payment_paypal.models.paypal: Validated Paypal payment for tx SO00703: set as done 2016-09-01 22:07:36,994 20222 INFO ema openerp.addons.website_sale.models.payment: transaction processed: tx ref:SO00703, tx amount: 0.1 2016-09-01 22:07:36,996 20222 INFO ema openerp.addons.website_sale.models.payment: transaction completed, confirming order SO00703 (ID 703)

and the blessed route is followed:

2016-09-01 22:07:37,527 20222 INFO ema werkzeug: 217.71.47.53 - - [01/Sep/2016 22:07:37] "POST /payment/paypal/dpn/ HTTP/1.0" 302 - 2016-09-01 22:07:37,968 20224 INFO ema werkzeug: 217.71.47.53 - - [01/Sep/2016 22:07:37] "GET /shop/payment/validate HTTP/1.0" 302 - 2016-09-01 22:07:38,373 20222 INFO ema werkzeug: 217.71.47.53 - - [01/Sep/2016 22:07:38] "GET /shop/confirmation HTTP/1.0" 200 -

And 4 seconds later the IPN arrives w/ the same address_city:

2016-09-01 22:07:39,139 20223 INFO ema openerp.addons.payment_paypal.controllers.main: Beginning Paypal IPN form_feedback with post data 2016-09-01 22:07:39,893 20223 INFO ema openerp.addons.payment_paypal.controllers.main: Paypal: validated data 2016-09-01 22:07:39,895 20223 INFO ema openerp.addons.payment_paypal.models.paypal: Received a notification from Paypal with IPN version 3.8 2016-09-01 22:07:39,903 20223 INFO ema openerp.addons.payment_paypal.models.paypal: Validated Paypal payment for tx SO00703: set as done 2016-09-01 22:07:39,915 20223 INFO ema openerp.addons.website_sale.models.payment: transaction processed: tx ref:SO00703, tx amount: 0.1 2016-09-01 22:07:39,917 20223 WARNING ema openerp.addons.website_sale.models.payment: transaction MISMATCH for order SO00703 (ID 703) 2016-09-01 22:07:39,926 20223 INFO ema werkzeug: 173.0.81.1 - - [01/Sep/2016 22:07:39] "POST /payment/paypal/ipn/ HTTP/1.0" 200 -

Unfortunately, when I try repeating the same steps I this time receive a GET request for the DPN:

2016-09-01 22:22:11,223 21033 INFO ema werkzeug: 217.71.47.53 - - [01/Sep/2016 22:22:11] "GET /payment/paypal/dpn/?amt=0.47&cc=EUR&charset=UTF-8&cm=%7B%22return_url%22%3A%20%22%2Fshop%2Fpayment%2Fvalidate%22%7D&item_name=SO00705&item_number=SO00705&st=Completed&tx=8R182095WE3841348 HTTP/1.0" 405 -

And 405 error as a result. IPN follows w/ successful verification (contains address not from Odoo form, but from the PayPal user I use to pay the SO).

So, it seems that PayPal responses are completely unpredictable. With a slightly more successful responses from the old UI.

ryanc-me commented 8 years ago

I know this is an old post, but I've followed a number of steps that have successfully fixed this issue. I'll leave my findings here for posterity.

Head over to the "My Profile" section on the PayPal website then ensure that:

Selling Tools -> Website preferences -> Auto Return for Website Payments is ON
Selling Tools -> Website preferences -> Return URL is set to https://mydomain.com/shop/confirmation
Selling Tools -> Website preferences -> Payment Data Transfer is OFF (this is what causes the 405 errors)
Selling Tools -> Instant payment notifications is set to https://mydomain.com/payment/paypal/ipn
Selling Tools -> PayPal button language encoding is set to UTF-8 in both drop-downs (you might have to click More Options)

Also check:

You've correctly set a dbfilter, either via the Odoo config file, or the dbfilter_from_header module. Ensure that visiting http://mydomain.com/web/database/selector only shows ONE database
Your Odoo config file contains proxy_mode = True

Under Settings -> Parameters -> System Parameters:

web.base.url is set to your website's URL (with the correct protocol; http:// or https://)
web.base.url.freeze is set to True (you may need to create a new parameter)

Finally, in Odoo under Accounting -> Payments -> Payment Acquirers:

Paypal Email/Merchant ID should be set (your Merchant ID can be found under My Profile on the PayPal website, email is just your login email)
Use IPN is TICKED
The Provider is Paypal
The Form Button Template is paypal_acquirer_button

Obviously replace mydomain.com with your domain, and make sure you're using the right protocol (http:// or https://). Here's the nginx config file that I've been using.

I can confirm that using the above settings, my cart is cleared, and customers are dropped on a nice Order Confirmed page after paying. Completed orders still show up in the To Invoice status, but the payments are definitely being seen and registered by Odoo.

willmakenoise commented 8 years ago

@MGinshe I've followed your steps, but it still does not work for me. I'm on a Digital Ocean server.

Still get this message after completing PayPal payment: Method Not Allowed The method is not allowed for the requested URL.

The only way I can avoid the error is by setting the return url in payment_paypal/controllers/main.py to shop/confimation

The only thing I have not done, is use the dbfilter_from_header module, as I don't have a use for it.

a0c commented 8 years ago

@MGinshe

I've followed a number of steps that have successfully fixed this issue

No, you've just followed the official Odoo documentation for 9.0. If it did work out of the box, this issue would not appear on GitHub in the first place.

a0c commented 8 years ago

@willmakenoise Changing return url is not good.

Adding this to the submit form doesn't help either: <input name="rm" value="2" type="hidden">

My current ugly (but working) solution is to allow GET method on paypal_dpn(), but then, instead of verifying paypal data in paypal_dpn(), just sleep in paypal_dpn() and wait until IPN gets validated by paypal_ipn() (typically happens within 10 seconds) -- and then proceed with werkzeug.utils.redirect(return_url) in paypal_dpn().

What makes this solution ugly is that I cannot find a way to know when the transaction is processed to done state by the paypal_ipn() running in a different worker than that of the paypal_dpn()'s. Passing a queue to every worker to use it to communicate the 'transaction done' event should work, but this would not be an elegant solution either.

So my users just have to wait 10 seconds of their lives w/o any particular reason :)

a0c commented 8 years ago

In the logs I posted above Paypal: answered INVALID on data verification happens when PayPal sends very strange data to /dpn route. In this data receiver_id == business, meaning that PayPal sends the merchant's data to Odoo, not the data customer provided on Odoo's website. payer_id and payer_email are those of the customer, though.

All in all, validation in the /dpn route fails when the following params are received: ['address_city', 'address_country_code', 'address_name', 'address_state', 'address_street', 'address_zip', 'business', 'charset', 'custom', 'first_name', 'handling_amount', 'item_name', 'item_number', 'last_name', 'mc_currency', 'mc_fee', 'mc_gross', 'payer_email', 'payer_id', 'payer_status', 'payment_date', 'payment_fee', 'payment_gross', 'payment_status', 'payment_type', 'protection_eligibility', 'quantity', 'receiver_id', 'residence_country', 'txn_id']. And the following keys do pass validation in the /dpn route: ['address_city', 'address_country', 'address_country_code', 'address_name', 'address_state', 'address_status', 'address_street', 'address_zip', 'auth', 'business', 'charset', 'custom', 'first_name', 'form_charset', 'handling_amount', 'item_name', 'item_number', 'last_name', 'mc_currency', 'mc_fee', 'mc_gross', 'notify_version', 'payer_business_name', 'payer_email', 'payer_id', 'payer_status', 'payment_date', 'payment_fee', 'payment_gross', 'payment_status', 'payment_type', 'protection_eligibility', 'quantity', 'receiver_email', 'receiver_id', 'residence_country', 'shipping', 'tax', 'transaction_subject', 'txn_id', 'txn_type', 'verify_sign']

Their difference: failing params don't contain these keys: ['address_country', 'address_status', 'auth', 'form_charset', 'notify_version', 'payer_business_name', 'receiver_email', 'shipping', 'tax', 'transaction_subject', 'txn_type', 'verify_sign']

Any ideas? Looks like PayPal is sending several types of messages along with the redirection. I would expect several message types on the IPN route, but definitely not on the return url (/dpn).

ryanc-me commented 8 years ago

@willmakenoise @a0c It might be worth double-checking some of the settings posted above - especially on the PayPal website (PDT, button encoding, etc).

When I originally launched my website, I followed the official Odoo guide and the suggestions from this thread. However, when I re-checked my PayPal account yesterday some of the settings had reset (namely PDT, which was ultimately what caused the 405 Method not Allowed errors in my case).

As an aside, are either of you using some sort of CDN or DNS service like CloudFlare or CloudFront?

willmakenoise commented 8 years ago

@MGinshe As I mentioned, I followed your steps, and it still does not work. I've had this problem for 8 months, so yes, I have double and triple checked everything.

No CDN.

willmakenoise commented 8 years ago

@a0c Well, from what I've gathered, allowing GET-method is not very secure.. so I'm stuck between two evils.

Could you post the code for what you described?

a0c commented 8 years ago

Oh dear... Guess how many times those settings were checked over and over again...

Even if PDT was the cause, allowing GET on the /dpn route would have solved the issue. But it hasn't.

And frankly I don't understand at all why the /dpn route calls the paypal_validate_data() method which follows the IPN protocol, which AFAIK has nothing to do with returning the customer to the website. The fact that it sometimes works is a bigger mystery for me than the fact that it fails at times.

No, no CloudFlare/Front here.

Could HTTP/1.0 vs HTTP/1.1 be the reason?

willmakenoise commented 8 years ago

This is kind of funny... We are not the only ones having these issues. (check the URL):

a0c commented 8 years ago

@willmakenoise Sure, here it is. It doesn't perform any validation on the received data, just waits for the IPN to arrive. So it should be safe to enable GET on it. How it works on the website (shopping cart):

if IPN arrives within e.g. 10 seconds, the route '/shop/payment/validate' will proceed to /shop/confirmation that will be automatically rendered as a good confirmation page (Your Order XXXXX is Confirmed, bla bla bla).
if IPN is too slow to arrive within 10 seconds, the route '/shop/payment/validate' will proceed to /shop -- sort of a graceful degradation.

Not the best solution, of course, but it has worked well so far. Also, what you can see from the code, I tried to wait for the transaction to be done -- so that I terminate the sleep as soon as IPN gets processed, but this straightforward solution doesn't work. I suspect it is because of the multi-processing, but still I don't get why exchanging data via DB doesn't work. Passing workers a queue for inter-process communication would be a little bit of overkill, I think.

a0c commented 8 years ago

@MGinshe @willmakenoise Guys, look what I've found! :) [FIX] payment_paypal: accept GET requests for Paypal DPN Just 2 days ago, in the main repo :)

bouvyd commented 8 years ago

Hello,

The commit odoo/odoo@3e4206b4d450 indeed adds GET support for reasons detailed in the commit message. However it does not change the way the /dpn and /ipn route works and the fact that both these routes should go through data validation. The message from @MGinshe seems like a good configuration sample to me.

I've tried changing the address during the Paypal checkout, this pass both ipn and dpn validation. Bypassing the /dpn route completely is not really a good idea, as it's the last fallback if IPN somehow fails (that's the reason the DPN route must go through data validation, because it's the only thing that can validate you transactions if IPN does not work/is not set).

Concerning the rm value, it is not necessary to set it in our case since it defaults to POST if IPN is set (see here).

@a0c I honestly don't know what causes you so much problems, but I stand by my commit message; the only scenario where I systematically receive a GET request is for payment without paypal accounts. And I believe DPN stands for Direct Payment Notification (the browser redirect).

I will now close this ticket, because as often with external integrations issues it has become a complete mixed bags of real and configuration problems; and the initial issue should be solved by the specified commit.

willmakenoise commented 8 years ago

@dbo-odoo If you look at my previously posted screenshot, it is from when I ordered an odoo experience pass from the official odoo store. I was logged in, and still got this message.

So apparently Odoo also has this problem. Are you saying that Odoo is struggling with finding the right config as well?

a0c commented 8 years ago

@dbo-odoo

Concerning the rm value, it is not necessary to set it in our case since it defaults to POST if IPN is set (see here).

In our case Auto Return is also set, and according to the link you've provided:

If you are using Auto Return, rm is irrelevant, as Auto Return is always a GET.

This is weird.

bouvyd commented 8 years ago

@a0c Quite right, I didn't see the note in that link. I must admit Paypal config is quite complex and unpredictable, as some settings tend to switch other things invisibly. I am 100% positive than an account with IPN on, PDT off and auto-return on sends GET requests; as it is the way I always test the paypal provider. I have found some public threads agreeing with this (here for example), but I am unable to find anything from paypal going in that direction or the other "officially".

@willmakenoise I actually didn't see the url in your screenshot until now! I'll have a look, we use a more recent version than Odoo 9.0 on our production server so this may be something else (but this very well may be a misconfig of Paypal).

a0c commented 8 years ago

But solving the GET/POST issue is still solving just one half of the problem. The other half is the Paypal: answered INVALID on data verification I see in the logs in half of the cases, although I don't change anything in PayPal/Odoo configuration in the meanwhile and do all the same steps when paying with PayPal.

From this I conclude that Odoo's transaction processing in the /DPN route should be different from tx processing in the /IPN route. Probably because of the different messages PayPal sends back.

E.g. when /DPN validation succeeds, the DPN's message is almost identical to what later on arrives as IPN: DPN's message doesn't have ipn_track_id key, but instead has 'auth': u'AcR8Bdv6b4y3ldGOm7TEmntc6JJUhcuFiioYo.wdMSAyOGsV2L2h0ei2gbJkLnAIWJQJIlId4MtV0.-4Ah4.JAg' and 'form_charset': u'UTF-8', keys. When /DPN validation fails, the DPN's message is much shorter than what later arrives as IPN. Some of the differences:

DPN: 'address_name': u'Anton Bla-bla', <== taken from Name on PayPal IPN: 'address_name': u'Company A Bla-bla', <== taken from Business Information on PayPal DPN: 'business': u'225PPBla-bla', <== same as receiver_id, i.e. Merchant account ID of seller IPN: 'business': u'info@bla.bla', <== Email address of seller

IPN: 'ipn_track_id': u'8a30d9e33c782',

DPN: 'payer_status': u'VERIFIED', IPN: 'payer_status': u'verified', DPN: 'payment_date': u'2016-09-01T22:38:35Z', IPN: 'payment_date': u'15:38:34 Sep 01, 2016 PDT', DPN: 'payment_fee': u'0.37', IPN: 'payment_fee': u'', DPN: 'payment_type': u'INSTANT_TRANSFER' IPN: 'payment_type': u'instant', DPN: 'txn_id': u'56E72605LR795670Y' IPN: 'txn_id': u'56E72605LR795670Y',

IPN: 'txn_type': u'web_accept', IPN: 'verify_sign': u'AFd.erwt7VoeoUMr85yut0RloHozA32aUlHG9k9HAIgk48tL94SBUYHe'

Basically, if the DPN and IPN messages are almost identical, calling the same validation method paypal_validate_data() as for IPN is completely OK for the DPN route. But once the messages are different, a different validation method should be implemented and used for the DPN route.

ryanc-me commented 7 years ago

@dbo-odoo @a0c After a little bit more tinkering, it looks like setting rm to 2 causes PayPal to treat /payment/paypal/dpn as a POST route. Using the config I posted above, and adding rm to the paypal button template, everything seems to be working fine (even without GET in the DPN route).

The module still isn't perfect - sometimes users are dropped onto the /shop page when returning from PayPal, instead of the /shop/confirmation page. I've had a look at the source code for both payment_paypal and website_sale, and it looks like the DPN validation is failing, causing the sale order to get stuck in the draft state. Usually the IPN callback comes through pretty quickly, so the order still gets validated and confirmed on the backend, but it would be nice for users to see a proper confirmation page after paying.

DidierLACOMBE commented 7 years ago

Hello

I am answering lattely

but my question is : is it necessary to have db name = domain name

IE through db_filter can I selecter any king of DB name, or is it mandatory to have db name = domain name

thanks

Didier Lacombe

didier.lacombe303@gmail.com

Tél : 00 33 (0) 6 20 57 32 20 Fax : 00 33 (0) 4 78 42 11 58

2016-09-13 14:08 GMT+02:00 Ryan Cole notifications@github.com:

I know this is an old post, but I've followed a number of steps that have successfully fixed this issue. I'll leave my findings here for posterity.

Head over to the "My Profile" section on the PayPal website then ensure that:

Selling Tools -> Website preferences -> Auto Return for Website Payments is ON

Selling Tools -> Website preferences -> Return URL is set to https://mydomain.com/shop/confirmation https://mydomain.com/shop/confirmation

Selling Tools -> Website preferences -> Payment Data Transfer is OFF (this is what causes the 405 errors)

Selling Tools -> Instant payment notifications is set to https://mydomain.com/payment/paypal/ipn https://mydomain.com/payment/paypal/ipn

Selling Tools -> PayPal button language encoding is set to UTF-8 in both drop-downs (you might have to click More Options)

Also check:

You've correctly set a dbfilter, either via the Odoo config file, or the dbfilter_from_header https://apps.openerp.com/apps/modules/9.0/dbfilter_from_header/ module. Ensure that visiting http://mydomain.com/web/database/selector only shows ONE database

Your Odoo config file contains proxy_mode = True

Under Settings -> Parameters -> System Parameters:

web.base.url is set to your website's URL (with the correct protocol; http:// or https://)

web.base.url.freeze is set to True (you may need to create a new parameter)

Finally, in Odoo under Accounting -> Payments -> Payment Acquirers:

Paypal Email/Merchant ID should be set (your Merchant ID can be found under My Profile https://www.paypal.com/businessprofile/settings/ on the PayPal website, email is just your login email)

Use IPN is TICKED

The Provider is Paypal

The Form Button Template is paypal_acquirer_button

Obviously replace mydomain.com with your domain, and make sure you're using the right protocol (http:// or https://). Here's the nginx config file https://gist.github.com/MGinshe/940c00bb6dd68b11cbb3ec3853cd2123 that I've been using.

I can confirm that using the above settings, my cart is cleared, and customers are dropped on a nice Order Confirmed page after paying. Completed orders still show up in the To Invoice status, but the payments are definitely being seen and registered by Odoo.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/odoo/odoo/issues/766#issuecomment-246660833, or mute the thread https://github.com/notifications/unsubscribe-auth/AQUcjUZIYtBO5XlY1nV0E16kpJleNbtlks5qppI3gaJpZM4CHePF .

joaopedrocampos commented 7 years ago

I'm having a very particular issue with this.

The return works perfectly on the website, but when I'm using my website on a mobile device, the return to store gives the Method Not Allowed error, any ideas?

l-arnold commented 7 years ago

One comment on this is that most of this discussion focuses on payments from the Website. My issue is that I have been having this error using "backend payments" where I have "show payment aquirers" enabled for my user. The effect of this is, if I confirm a Quotation to become a Sales Order, I am presented with the "Pay with PayPal Button". This is quite convenient to then go through the process but I end up with a "Method not allowed" when PayPal tries to return me to the site.

As I have not been using the Web page functionally to sell from the Odoo Site (I am connected to Magento instead) I do not know if my system is working on the Web site. I have gone through, as much as possible, all of the excellent steps outlined by MGinsche above (thank you for detail there).

I do expect the variation between "backend" and "frontend" can cause some issues but my question is whether the IPN return page (or the return_url) should be different for each of them.

odoo / odoo

"Return to store" link from PayPal gives 405 error in Odoo #766

Impacted versions

Steps to reproduce

Current behaviour

Expected behaviour

access_log off;

access_log off;

Return URL: https://yourdomain.com/payment/paypal/ipn

Payment Data Transfer: Off

Return URL: https://yourdomain.com/payment/paypal/ipn

Payment Data Transfer: Off

Return URL: https://yourdomain.com/payment/paypal/ipn

Payment Data Transfer: Off

Return URL: https://yourdomain.com/payment/paypal/ipn

Payment Data Transfer: Off