Context
See this question: Enable CORS on Azure Service Bus Namespace
Really I want to have a front-end only ReactJS app that talks to the Azure API, and renders bits of the result onto the screen. Then gets input from the users and sends that back to the Azure API. Rinse and repeat.
Unfortunately CORS pretty much rules that out, and you can't[1] override the CORS rules for a ServiceBus Namespace.
So the proposed solution is a thin proxy server, proxying the Azure API, to circumvent CORS.
(Alternative solutions to this question are HIGHLY welcome!)
[1] read: I can't currently see any way to, and nor can my Google Searches.
Question
The user on that other question proposes the relevant web.config file, so now I want to create that proxy server. I don't really want that server doing anything else, I want it to be as transparent as possible.
What is the simplest possible way to set up that server?
I'm kinda hoping that I would be able to do something like:
"Tell Azure that I want a webserver, and paste/upload that web.config text into the Azure Portal"?
If it's relevant, currently my stack has literally nothing other than npm and the JS Create-React-App template's stack. I'm imagining we'll host the site in Azure too.
I got this to work, and it was pretty painless - Azure can JustDoThis.
Documenting the notes I wrote for myself here, for any future lost wanderers :)
As noted in the linked question, the Azure server doesn't (and can't) enable CORS, so we need to circumvent that in some manner. The approach is to create a ReverseProxy server, which accepts the request, forwards it to Azure, receives the response, adds the relevant CORS headers and and returns it to the caller.
Followed steps, except skip the "Basic Authentication" step (Steps #3 & #4), from this Microsoft blog: https://blogs.msdn.microsoft.com/mihansen/2018/04/18/reverse-proxy-with-basic-authentication-in-azure-web-app/
Step 1: Create a new Azure Web App
Step 2: Add applicationHost.xdt file (in \Home\site)
Step 2a: Set the contents of the .xdt file using provided template (I think it's literally a web.config file?
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.webServer>
<proxy xdt:Transform="InsertIfMissing" enabled="true" preserveHostHeader="false" reverseRewriteHostInResponseHeaders="false" />
</system.webServer>
</configuration>
SKIP STEPS 3 & 4 (relate to Authentication which isn't necessary if it's just a redirect.)
Step 5: Update/Modify/Create rewrite rules
Step 2 is achieved through KUDU, which is accessible here:
https://yourazuresitedomain.scm.azurewebsites.net/
Some links about what KUDU is and how to use it:
https://blogs.msdn.microsoft.com/benjaminperkins/2014/03/24/using-kudu-with-windows-azure-web-sites/
https://www.jamessturtevant.com/posts/How-to-add-edit-and-remove-files-in-your-azure-webapp-using-the-kudu-service-dashboard/
Related
Ghost blog platform has a setting that allows you to change the admin panel login location (which starts as: https://whateveryoursiteis.com/ghost). Methodology / docs for changing that setting can be found here: https://ghost.org/docs/config/#admin-url
However — when using the above methodology the API Url that is used for Search etc etc is ALSO modified meaning all requests to the ghost API will also be forwarded to the alternate domain (not just the admin access).
My question is — what is the best way to achieve a redirect of the admin URL to a different Domain / protocol while allowing the API url used by Ghost to remain the same?
More background.
We are running ghost on top of GKE (Google Kubernetes Engine) on a Multi-Region Ingress which allows us to dump our CloudSQL DB down to a SQLite file and then build that database into our production Docker Containers which are then deployed to the different Kubernetes nodes that are fronted by the GCE-Ingress load balancer.
Since we need to rebuild that database / container on content change (not just on code change) we need to have a separate Admin URL backed by Cloud SQL where we can persist / modify our data which then triggers the rebuild on our Ci pipeline via Ghost Webhooks.
Another related question might be:
Is it possible to use standard ghost redirects (created via: https://docs.ghost.org/concepts/redirects/) to redirect the admin panel URL (ie. https://whateveryoursiteis.com/ghost) to a different domain (ie. https://youradminsite.com/ghost)?
Another Related GKE / GCE-Ingress Question:
Is it possible to create 301 redirects natively using Kuberentes GCE-Ingress on GKE without adding an nGinx container etc?
That will be my first attempt after posting this — but I figured either way maybe it helps another ghost platform fan down the line someplace — I will attempt to respond back as I find answers to those questions (assuming someone doesn't beat me to it!).
Regarding your question if it's possible to create 301 redirects without adding a nginx container, I can suggest to use istio, find out more information about traffic routing here.
OK. So as it turns out the Ghost team currently has things setup to point API connections at the Admin URL. So if you change your Admin URL expect your clients to attempt to connect to that URL.
I am going to be raising the potential of splitting these off as a feature request over on the ghost forums (as soon as I get out from under pre-launch hell on the current project).
Here's the official Ghost response:
What is referred as 'official docker image' is not something that we
as a Ghost team support.
The APIs are indeed hosted under the same URL as the admin and that's
by design and not really a bug. Introducing configuration options for
each API Ghost instance hosts would be a feature and should be
discussed at our forum first 👍 I think it's a nice idea to be able to
serve APIs from different host, but it's not something that is within
our priorities at the moment.
In case you need more granular handling of admin site, you could
introduce those on your proxy level and for example, handle requests
that are coming to /ghost/api with a different set of rules.
See the full discussion over here on the TryGhost GitHub:
https://github.com/TryGhost/Ghost/issues/10441#issuecomment-460378033
I haven't looked into what it would take to implement the feature but the suggestion on proxying the request could work... if only I didn't need to run on GKE Multi region (which requires use of GCE-Ingress which doesn't have support for redirection hah!). This would be relatively easy to solve the nGinx ingress.
Hopefully this helps someone — I will update as I work through the process. As of now I solved it by dumping my GCP CloudSQL database down to a SQLite db file during build time (thereby allowing me to keep my admin instance clean and separate from the API endpoint — which for me remains the same URL).
We are using WSO2 Carbon 4.2.0 through the WSO2 Application Server (AS) package. In replacing an older, highly customized Carbon installation (provided by a company that no longer supports the product, has abandoned it and refuses to work on it, and left us no details on how/what they modified in Carbon), we have deployed a couple web applications in the webapps container as they were deployed before in the older instance. We have changed our WebContextRoot in the carbon.xml from the default "/" to a sub-URL of ex: "/stuff", as is also detailed in the self-answered SO question here. However the answer given there is not detailed in what the OP actually encountered when he modified his WSO2 instance.
In testing the above configuration we noticed that if a user were to go to a non-existent web address on the server, depending on the format of the URL they are either:
redirected to a blank page;
receive a "500 Internal server error" (I suspect this is the embedded Tomcat?);
get sent to the Carbon login page (which we definitely do not want to happen for security reasons); or
get an XML document stating:
<faultString> The service cannot be found for the endpoint reference (EPR) /stuff/services/nonexistantservicename </faultString>
At least in the case of missing content we wish the user to be sent to a standardized 404 error page, or at the least be sent an HTTP 404 error by the server. For services the XML error is palatable, we can deal with that.
The only option for us right now to circumvent this issue is to place a proxy in front of the WSO2 instance, which would be another layer to manage and tune, and possibly degrade performance. Please know that I am not a programmer but just an admin with DevOps experience. I would not know how to handle this with e.g. a Java solution or re-coding parts of WSO2. Customizing the core product would also hamper future upgrades of WSO2, a scenario we are trying to dig ourselves out of now as detailed above. Is there no internal WSO2 mechanism to handle non-existent content? Can we not redirect any errors to a standard canned response page?
This problem seems to exist on a specific server. All other servers are working ok.
Background: The website is basically Forms Auth but there's an asmx that manually requires Basic Auth.
I have two C# client.
When invoking using SOAP (asmx client proxy) with basic auth credentials - all is well.
When invoking using WebClient or WebRequest with the same basic auth credentials, I get 401.5.
The folders have "Everyone" set to them.
When setting up iis trace, I see a very weird behavior. The request arrives with the correct Basic auth header. But further down the trace I see the following:
GENERAL_REQUEST_HEADERS
Headers="Connection: Keep-Alive
Content-Length: 68
Content-Type: application/json
Authorization: Kerberos
Expect: 100-continue
Host: 1.2.3.4
The Kerberos seems very weird. It is as if the request headers changed throughout the process, and perhaps that explains the 401.5.
Again, I would like to stress out that on other servers there's no problem with both clients. The only difference I can think of is that the problematic server is a DC. But if that is a problem then why is the SOAP client working well?
Any ideas?
Progress!
After some debugging I noticed that Application_AuthenticateRequest was fired twice for every request. The first time with Basic auth as I expected and the second time with the Kerberos!
After googling I found this:
http://forums.asp.net/t/1868629.aspx?HttpModule+triggered+two+times+for+request+to+URL+without+default+document
Seems like for extensionless urls those events might fire multiple times, depending on the configured Extensionless urls.
Going back to the trace I noticed that in the non-working server the trace shows usage of ExtensionlessUrl-ISAPI-4.0_64bit, and in the working servers no such entry existed. After comparing the two IIS I noticed that the non-working IIS had ExtensionlessUrl-ISAPI-4.0_64bit configured whereas in the working IIS there was ExtensionlessUrl**Handler**-ISAPI-4.0_64bit (note the "handler"). I compared the dlls involved and the working server had a newer aspnet_isapi.dll. I assume that this is an updated extensionless url handler. I suppose an upgrade to IIS or .NET might install a later version, but for now I tried to remove the ExtensionlessUrl-ISAPI-4.0_xxbit like so:
<remove name="ExtensionlessUrl-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrl-ISAPI-4.0_64bit" />
And it worked! Now there is only a single Application_AuthenticateRequest.
The non-working version that had this in the trace:
OldHandlerName="", NewHandlerName="ExtensionlessUrl-ISAPI-4.0_64bit", NewHandlerModules="IsapiModule", NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Now changed to:
OldHandlerName="", NewHandlerName="WebServiceHandlerFactory-ISAPI-4.0_64bit", NewHandlerModules="IsapiModule", NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Hopefully that's the end of it. Additional testing still required.
I would appreciate if someone can write how to upgrade IIS dlls to a later version. Is this an upgrade to .NET or is there a specific KB update that is downloaded with Windows Update?
How can I only allow requests from my Apache Server in the DMZ access to WildFly over AJP, and block everything else?
This answer works great at deployment level but I would prefer control at the server-level :
At the moment only way to do this is by implementing ServletExtension and add extra handlers that will take care of that.
see http://undertow.io/documentation/servlet/servlet-extensions.html for more on writing extensions
and example of using it:
https://github.com/undertow-io/undertow/blob/master/core/src/test/java/io/undertow/server/handlers/IPAddressAccessControlHandlerUnitTestCase.java
In any case I would encourage you to create new feature request in undertow jira to add proper support for this. Issue tracker can be found at: https://issues.jboss.org/browse/UNDERTOW
Our team is completely new to the WSO2 tool. We got the basic training on how to add proxy services and were able to do so as well.
Now, we have to add a class in the In Sequence. We tried that using the Class mediator but it was not able to find the class. Then we realized that the jar file needs to be in the components/lib folder. So, its able to load the class now. It proceeds to the out sequence and fault sequence properly. But, in the end, it gives the following exception.
Unable to add proxy service :: Failed to add proxy service: Parse. Check whether the Proxy already exists-Failed to add proxy service: Parse. Check whether the Proxy already exists
So far, we're using the design view to configure it. I surveyed through most of the posts within this forum, and, all are using the source code to configure. Also, the proxy service is not present in the Source View section under Service Bus.
Are we missing any step in the configuration? Do we need to switch to coding method or it is possible this way.
Your explanation is strange. Above mentioned error log can appear at the time of deploying the proxy service. But you say your proxy is going to the out-sequence and fault-sequence. From that what I understand is the proxy is already deployed.
You can check whether a proxy with the same name is there by looking in the ESB_HOME/repository/deployment/server/synapse-config/default/proxy-service folder. If there is a file with name Parse.xml (I think the name of the proxy service is Parse) you can delete it from the file system and then go to the design view and add the proxy again.
It seems there is already a proxy with the name you provided. Go to WSO2 ESB "source view" and check whether there exist a proxy with that name. Source view is available on the left side of the management console.
This artical will take you step by step in writing custom class mediators.
This post may also be relevant for you.