Question about AppDashboard URL rewrite

[Carolina Simões Gomes]

Hello!

As the next step on the user authentication work I'm doing with AppScale, I need to have 2 things happen.

1. The AppDashboard URL (say, http://192.168.122.119:1080, which then gets converted to the SSL URL, https://192.168.122.119:1443) must not be visible like that from the client side. In other words, I don't want a permanent redirect to happen.

Instead, I would like the client-side URL to remain that of the app (say, gae_clock.edgescale.net) or at least for the AppDashboard IP to not show up, and be just a URL instead (like auth.edgescale.net).

2. Further, I want the "continue" URL passed on to AppDashboard by GAE's UserService.createLoginURL() and UserService.createLogoutURL() to NOT be the applications's IP, but the application's URL instead. 

I have partially succeeded in  doing that by passing req.getServerName() as param to createLoginURL()/createLogoutURL(), where "req" is the app's HttpServletRequest class. 

In that case, the "continue?" part of the login URL indeed becomes the server name (e.g. gae_clock.edgescale.net) BUT for the logout URL, it is still the app's IP. I am not sure why.

I know that's a lot of info but basically my question is if you have any insights on how to go about making changes such that AppScale behaves the way I want as described above. For example, what changes should I make to the nginx configs (in AppController/lib/nginx.rb) such that instead of having a permanent redirect to AppDashboard, the login request is simply proxied to AppDashboard and the client-side URL is not changed? I tried changing configs to "proxy_pass" instead for example, or having a temporary redirect instead, but that failed.

[chris....@appscale.com]

Hi Carolina,

I think most of the functionality you are looking for can be approximated by adding `login: your.dns` to your AppScalefile. The implementation for this has several downsides, though:

• The dashboard port is still visible on the login URL. Avoiding this would be difficult since we would need some mechanism for deciding which application requests to intercept.
  
• If you need an SSL cert for your app, you need to create a new file in /etc/nginx/sites-enabled with a server block that will listen on that dns name with the right cert location set. This is because the AppController can overwrite the other files there.
• The login parameter is currently deployment-specific instead of app-specific. We have a ticket open for this.
  
• By default the Python AppServer uses wsgi environment vars to determine the host while the Java AppServer uses the value of `login` (or the IP address if `login` is not defined).

This area could be a lot more polished, so if you have any ideas about how to improve the configuration or implementation for this, we would love to hear them.

[Carolina Simões Gomes]

Thanks for your response!

When I set the login address in AppScalefile, is it OK if I use an URL like auth.edgescale.net instead of an IP address? Looks like node_layout.py in appscale-tools has a check against that, and wondering if making changes to it will have any bad side effects.

[chris....@appscale.com]

Yes, a DNS name should be fine. Make sure to put the `login` key outside of `ips_layout`. I believe the check in node_layout that you mentioned is just for the contents of ips_layout.

[Carolina Simões Gomes]

Thanks, that worked :-) Now I will just have to change the Java AppServer to accept the destinationUrl (passed in UserService.createLogoutUrl/createLoginUrl) as continuation URL, instead of using the default 'login' value. Will let you know if I face any other issues!

On Wednesday, July 13, 2016 at 7:22:44 PM UTC-4, Carolina Simões Gomes wrote:

[Carolina Simões Gomes]

Hello!

I have another question: I have made changes to LocalLoginServlet.java and LocalUserServlet.java in AppServer_Java such that the NGINX_ADDR and NGINX_PORT of the app being authenticated are used to retrieve the app URL (say, gae_app.domain.com) from an external web service. The idea is for the user to not be able to see what port of the login server the app is listening on.

So for example, the path for authentication becomes:

<login server URL>:1443/login?continue=gae_app.domain.com?continue=gae_app.domain.com

That works in the sense that after authentication, the URL gae_app.domain.com shows up in the web browser, rather than <login server URL>:<app port>

However, when, say, UserService.getCurrentUser() is called after the authentication, instead of returning a non-NULL value the method still returns NULL as though no authentication happened. But if instead of using continue=gae_app.domain.com I use continue=<login server URL>:<app port>, then the method returns non-NULL and thus authentication really happened.

Any insights on what I am doing wrong or where I should look into to solve the issue?

Thank you!

On Wednesday, July 13, 2016 at 7:22:44 PM UTC-4, Carolina Simões Gomes wrote:

[chris....@appscale.com]

It may be a cookie issue. I would check the first request after you log in to see whether there's a 'Cookie' header set.

If the cookie header is missing, you can try setting the domain in the response.set_cookie call in AppDashboard/lib/app_dashboard_helper.set_appserver_cookie. To verify that it worked, the set-cookie header you get from the POST to <login server>:1443/users/login should include a 'Domain=gae_app.domain.com'.

Also, make sure that the login server domain meets the matching requirements for the app domain. For example, if the login server was auth.gae_app.domain.com, it should be fine. The browser won't set a cookie for a completely different domain, though.

[Carolina Simões Gomes]

Didn't have time to reply before, sorry :-) The solution worked perfectly! Thanks a lot.

On Wednesday, July 13, 2016 at 7:22:44 PM UTC-4, Carolina Simões Gomes wrote: