Project

General

Profile

Actions

Bug #2694

closed

OAuth redirect url not working in Wt 3.3.2-rc1

Added by Marco Gulino over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Roel Standaert
Target version:
Start date:
02/20/2014
Due date:
% Done:

0%

Estimated time:

Description

Hello

I'm using both a username/password login and oauth on my webapp.

I tried using wt 3.3.2-rc1, and the result is that when I click the oauth button (either facebook or google) instead of closing the popup window and reloading the website (authenticated) I just get a new (and not authenticated) session inside the popup window.

The only strange thing I can see in my log is:

[2014-Feb-20 17:14:37.943304] 16982 [/SkyPlanner nbROBi02M0xJZRSg] [warning] "WMenu: unknown path: 'googleOAuth2Callback/'"

Another hint: my webapp is deployed under apache with a mod-proxy, I'm using whttpd with ---deploy-path /MyAppName

Actions #1

Updated by Koen Deforche over 10 years ago

  • Status changed from New to Feedback
  • Assignee set to Koen Deforche
  • Target version set to 3.3.2

Hey,

I think you're simply missing something in your reverse proxy configuration for the 'static resource' that is involved in OAuth; see also:

http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1Auth_1_1OAuthService.html#add76eee14370693fa109c2768ca70725

You should take a look at the access log (in your apache server) for a request to a URL that is not in /MyAppName ?

Also since you reverse-proxy, are you having the same external path as the internal one (/MyAppName) ? If not there may be other complications to configure things correctly.

Regards,

koen

Actions #2

Updated by Marco Gulino over 10 years ago

I thought about that, but I can't find anything strange in my configuration; also it's working back again if I reinstall wt 3.3.1.

By "static resource" you mean the "google/facebookOAuth2callback" path, I think, correct?

This is what I have anyway:

apache conf:

ProxyPass /SkyPlanner http://localhost:8086/SkyPlanner retry=10

ProxyPassReverse /SkyPlanner http://localhost:8086/SkyPlanner retry=10

app command line: src/SkyPlanner ---http-address 0.0.0.0 ---http-port 8086 ---docroot /usr/share/Wt/ ---accesslog SkyPlanner.Access.log ---deploy-path /SkyPlanner -c wt_config.xml

wt_config xml oauth section:

http://gulinux.net/SkyPlanner/facebookOAuth2callback

/SkyPlanner/facebookOAuth2callback

In my apache log file I can see that the url "GET /SkyPlanner/facebookOAuth2callback?code=...." is (correctly, I guess) called.

Thanks

Marco

Actions #3

Updated by Koen Deforche over 10 years ago

  • Status changed from Feedback to InProgress
  • Assignee changed from Koen Deforche to Roel Standaert

Hey,

So somehow, the web service call does end up in wthttpd, but it is not being handled by the static resource?

That is unexpected; even though they share the same prefix, wthttpd will select the most specific entry point for the incoming request. As you indicate it used to work, this must be a regression in the wthttpd.

Roel, can you check if due to the many changes, we somehow broke the bestMatch logic in RequestHandler ?

Regards,

koen

Actions #4

Updated by Marco Gulino over 10 years ago

I just built a test environment with wt 3.3.2-rc1, leaving the "production" website with wt 3.3.1.

I did another test and watched, the wthttpd access log, I can confirm that apache correctly sends the request to wthttpd.

127.0.0.1 - - [2014-Feb-21 14:04:18.704659] "GET /SkyPlanner/googleOAuth2Callback?state=.....%3D%3D%7Chttp://test.gulinux.net/SkyPlanner?wtd..... HTTP/1.1" 302 0

Actions #5

Updated by Roel Standaert over 10 years ago

  • Status changed from InProgress to Resolved

Hey,

There was indeed a regression in wthttpd. I fixed it.

Regards,

Roel

Actions #6

Updated by Koen Deforche over 10 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF