I want to lock down a wordpress (PHP) project on GAE to be accessible only to domain users. I set up my app.yaml so all routes are login: required or login: admin , and in the appengine.google.com console, set it to use the "Google Apps domain" authentication type.
At first, it worked. However, now even if you are signed in to the domain, it behaves as if you are not authorized (returns error 500). I suspect that the difference is the instance was already warmed up the first time, whereas the second time, it was not.
Any way around this / has anyone experienced this problem and found a solution?
Related
I recently deployed a web app to test out Azure as a hosting platform.
The configuration is php 8 with local git. I was able to connect through git and deploy a website. When I try to navigate to the site I get a 404 error. I did some digging and if I use: myapp.azurewebsites.net/.auth/login/aad/callback it will redirect a couple times and take me to a landing page and then from there on I can navigate to my website... at least until the session ends and then I'm back to 404 errors.
This is a free azure deployment there is no special configuration or setup... I'm really just testing out azure as a hosting platform and wondering how to solve this issue.
The site is also configured such that only members of the tenant can access the site, which is by design, and I can authenticate and access the site but only after using myapp.azurewebsites.net/.auth/login/aad/callback
I would have expected.. so long as I have logged in and have an open session / cookie then I can freely navigate the page without first needing to use the callback
I suspect some sort of authentication or redirect issue but I've also followed the instructions in:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
The app registration from step 1 was already done as part of the deployment of the site. Kind of odd that after I use the callback URL I'm able to access the site as normal for a while.
Suggestions?
Thanks!
Local and preproduction versions of my website have same configs and same source code. For some reason preproduction version unable to communicate with Facebook API. When I'm trying to login using Facebook I'm getting such strange error:
Google translates the error message like this:
"You can not load the URL: field is not a URL is included in this application areas. To download this URL, please add all domains and sub-domains for your application to the "application domains" field in the application settings."
I have tried to add my domain to the list, but it didn't help.
The truth is, I'm stuck and I would be grateful for any hint what to do with the error.
P.S. Also I have no idea why the error message is in Arabic - Server from Germany and has en_US.utf8 locale.
Update Settings Basic (domain name changed)
Finally I found the issue. I've used cascade of reverse proxies (nginx), which modified $_SERVER['SERVER_PORT']. The modification leaded to inconsistency between generated redirect_uri and the value was specified in app settings in Facebook developer console.
As per the title - I'm trying to trigger an Azure Website "triggered" WebJob from our custom PHP deployment application hosted external to Azure websites.
Thanks to what I believe is Active Directory, I'm able to navigate the /api URLs in my browser and get a JSON output without having to reauthenticate. For example, /api/triggeredwebjobs outputs the triggered WebJob information (that I've set up inside Azure Portal) in my browser.
I've gotten as far in my PHP app as sending a POST request and it is successfully authenticating using basic auth, but every single /api URL that I set in my PHP app returns:
"No route registered for '/api/triggeredwebjobs/{webjobname}'"
where {webjobname} is my custom name for the web job, hidden for privacy of the client. Every URL returns this, but if I navigate in my browser, I only get that error if I navigate to a URL that doesn't exist, such as /api/blahblahblah.
I've set up a deployment user which is what it's using to authenticate... I've even logged in to https://{azuresite}.scm.azurewebsites.net/basicauth using the deployment user and successfully gotten output from each /api page in my browser.
If it helps, I'm using Httpful.phar to handle the HTTP requests.
Thank you very much for taking the time to read and possibly assist.
A colleague helped me get to the bottom of this - the documentation was out of date. I have opened an issue on the Kudu Github Repo to get them to review this:
https://github.com/projectkudu/kudu/issues/1466
To solve the issue for future readers of this question, the correct URL to use within the requester app is:
https://{yoursite}.scm.azurewebsites.net/jobs/triggered/{jobname}/run
Good luck!
I'm trying to set up a Wordpress Multisite network on Google App Engine. I have the install up and running, and am mapping custom domains for each site with the help of this plugin. I'm using Wordpress 4.0.
The domain mapping works, in that when I navigate to the custom domain it pulls up the corresponding site, but when I try to access any admin pages from the custom domain, I get an SSL error. I gather that this is due to Google's not allowing custom domains to access GAE apps via SSL, and so I've been trying to fix this by redirecting all requests of the form mycustomdomain.com/wp-admin/(.+) to myapp.appspot.com/wp-admin/\1.
My rationale for trying this is that myapp.appspot.com/subsite/wp-admin/ works just fine, but mycustomdomain/wp-admin does not, despite the two pointing to the same location.
Unfortunately, I haven't been able to figure out how to do this redirection properly. I've tried adding redirect rules to the .htaccess file with no success. I've also tried messing with app.yaml handlers, but this, too, yielded no results.
Also worth noting is that I attempted to force all requests to go through http (as a hackish, temporary workaround) via this plugin to no avail.
I'm new to working with servers, and any help would be much appreciated. I'm not even sure that redirection is the right solution, so I welcome any other suggestions. I can supply pertinent code if needed. Thanks.
EDIT: I could go through Google's custom domain registration process via Google Apps and get an SSL certificate that way, but my app will eventually be used by a large number of independent sites that I don't control, so that solution won't work.
I have been trying to achieve something similar on a regular server and not on GAE, so I'm not sure this will apply to you...
Isn't the 4th option of the Domain Mapping what you're looking for? In the WP network administration, go to Settings > Domain Mapping, then you can tick/untick the 4th option :
4. Redirect administration pages to site's original domain (remote login disabled if this redirect is disabled)
This will allow you to use a custom domain to access a site and its wp-admin interface, allowing SSL certificates to validate since the domain stays the same.
I am currently in the process of creating a mobile version of my web app.
The app is being developed with Facebook's PHP Client Library.
The issue:
I am using the following mobile url to allow users to log in using the mobile devices:
http://m.facebook.com/tos.php?api_key=APIKEY&v=1.0&next=http%3A%2F%2Ftweelay.net%2Fm.php&cancel=http%3A%2F%2Ftweelay.net%2Fm.php
APIKEY being my app's actual Facebook API key.
In the url I am telling Facebook to redirect the user back to http://tweelay.net/m.php when the user signs in or clicks cancel on the log in screen. I am pulling my hair trying to figure out why it keeps sending the user to http://m.tweelay.net/m.php which is currently an invalid end point.
I have gone through all of my app's settings on Facebook and I cant find any that reference http://m.tweelay.net and going through all of my source code I cant find any that reference the m. sub-domain either.
Any ideas? Is there a setting I'm missing? Maybe a Flag in the library?
I've seen Facebook do this when detecting the mobile browser type and also sometimes randomly through Firefox (it can also happen when trying to get to facebook.com). I've managed to reset it sometimes, but it's not a guaranteed fix.
If you want to be sure the user makes it to your correct site I suggest creating the subdomain and redirecting traffic to your usual site, it's what I did and now I don't worry about it reverting back.