Quarkus app to reverse proxy another old CGI web app - reverse-proxy

Does Quarkus provide a Guide to reverse proxy a old CGI web app?
I have 3 requirements
Put OIDC in front of the old web app
When a session starts, fill in the returned "log in" page, submit that log in page, and return the log in response
When required, Inspect a response from the old web app for data to use outside of the old web app.
I have requirement 1 completed with a simple servlet. requirements 2 and 3 are works in progress.

We currently do have any such guides on the website.

I used this proxy servlet
It works in Quarkus
<dependency>
<groupId>org.mitre.dsmiley.httpproxy</groupId>
<artifactId>smiley-http-proxy-servlet</artifactId>
<version>1.11</version>
</dependency>

Related

How do I configure stand alone Blazor WebAssembly app to allow incoming cross origin redirect?

Objective is to integrate payment gateway to from Stand alone Blazor WebAssembly application. My payment page component has a form that submit directly to the payment gateway like this:
<form action="https://gateway.bank.com" method="POST">
Clicking submit button in the form redirects correctly. After the user complete payment transaction on the bank page, user is redirected back to my app along with response header. Although the redirected url is correct, browser throws 404. Reading more, I found out that since the request is originated from another domain, it gets blocked by CORS. Read many articles about configuring CORS policy for server, but how do I configure it on the client app to allow incoming requests?
Tried the following:
Added Nuget package Microsoft.AspNetCore.Cors
Inserted [DisableCors] attribute on the page
Added CORS policy on Main()
builder.Services.AddCors(options =>
{
options.AddPolicy("Open",
builder => builder.AllowAnyOrigin().AllowAnyHeader());
});
None of these worked though.
Just to ensure the approach is correct I have implemented solution using razor pages with [IgnoreAntiforgeryToken] on page model; it is successful. Help appreciated to find where am I going wrong with WebAssembly. Kindly note that I don't have a server project, only a stand alone WebAssembly project.
If the request is being blocked by CORS, there is nothing you can do on your website to avoid this. CORS is a security mechanism of browsers inspecting the response from a server. If the server does not add the proper CORS header to the response, the browser blocks the response from getting to the site loaded in the browser.
This is an intentional and good (if sometimes frustrating) part of the internet. You would need to contact the bank and request your website be added to the list of allowed origins. They would add your website's URL to the Allow-Access-Allow-Origin header. Because your URL is now part of the cool-kids list, the browser will allow the response to reach your site and will no longer throw a CORS error.

How to enable offline support when using HTML5 history api

What are the best practices (and how to go about doing it) to support offline mode when using html5 history api for url rewrites?
For example, (hypothetically) I have a PWA SPA application at https://abc.xyz which has internationalization built in. So when I visit this link, the Vue router (which ideally could be any framework - vue, react, angular etc.) redirect me to https://abc.xyz/en.
This works perfectly when I am online (ofcourse, the webserver is also handling this redirect so that app works even if you directly visit the said link).
However, its a different story when I am offline. The service worker caches all resources correctly so when I visit the URL https://abc.xyz everything loads up as expected. However, now if I manually type the URL to https://abc.xyz/en, the app fails to load up.
Any pointers on how to achieve this?
Link to same question in github: https://github.com/vuejs-templates/pwa/issues/188
Yes, this is possible quite trivially with Service Workers. All you have to do is to configure the navigateFallback property of sw-precache properly. It has to point to the cached asset you want the service worker to fetch if it encounters a cache miss.
In the template you posted, you should be good to go if you configure your SWPrecache Webpack Plugin as follows:
new SWPrecacheWebpackPlugin({
...
navigateFallback: '/index.html'
...
})
Again, it is absolutely mandatory that the thing you put inside navigateFallback is cached by the Service Worker already, otherwise this will fail silently.
You can verify if everything was configured correctly by checking two things in your webpack generated service-worker.js:
the precacheConfig Array contains ['/index.html', ...]
in the fetch interceptor of the service worker (at the bottom of the file), the variable navigateFallback is set to the value you configured
If your final App is hosted in a subdirectory, for example when hosting it on Github pages, you also have to configure the stripPrefix and replacePrefix Options correctly.

Separate back-end and front-end apps on same domain?

We are building a fully RESTful back-end with the Play Framework. We are also building a separate web front-end with a different technology stack that will call the RESTful API.
How do we deploy both apps so they have the same domain name, with some URLs used for the backend API and some for the front-end views?
For example, visiting MyDomain.example means the front-end displays the home page, but sending a GET to MyDomain.example/product/24 means the back-end returns a JSON object with the product information. A further possibility is if a web browser views MyDomain.example/product/24, then the front-end displays an HTML page, and that webpage was built from a back-end call to the same URL.
Finally, do we need two dedicated servers for this? Or can the front-end and back-end be deployed on the same server (e.g. OpenShift, Heroku)
You are gonna to dig yourself... deep :)
Simplest and most clean approach with no any doubt is creating a single application serving data for both, BE and FE, where you differ response (JSON vs HTML) by the URL, pseudo routes:
GET /products/:id controllers.Frontend.productHtml(id)
GET /backend/products/:id controllers.Backend.productJson(id)
Benefits:
single deployment (let's say to Heroku)
name space managed from one app
No need to modify the models in many apps after change in one of them
else if
If you're really determined to create a two separate apps, use some HTTP server as a proxy - for an example nginx - so it will send all requests to domain.tld/* to application working at port 9000 (which will answer with HTML) but requests to domain.tld/backend/* redirect to application working at port 9001 responding with JSON.
else
If you are really gonna to response with JSON or HTML depending on the caller you can try to compare headers to check if request was sent from browser or from AJAX call in each controller , but believe me that will become a nightmare faster than you thing... insert the coin, choose the flavor
I thought of a different solution. I'm going to deploy back-end to a subdomain like
http://api.myapp.example/
and deploy front-end to the main domain:
http://myapp.example/
but I think you'd better use 2 different hosts, one for front-end and one for back-end (I searched the Google and this was the result of my investigations
Other possibility (therefore as separate answer) is using a possibility added in Play 2.1.x a Content negotiation I think it's closest for that what you wanted to get initially :)
Indeed its much easier to create a MEAN STACK APP and use one hosting like Heroku for instance.
Your frontend is what it is, front end for your backend. It will be easy to access backend / restfulAPI's and frontend like this:
http://localhost:3000/api/contacts (to access and consume your API endpoint)
http://localhost:3000/contacts (frontend)
NB: localhost:3000 or http://yourapp.example/api/contacts (api)
http://yourapp.example/contacts (frontend)
It's in the URL

SWT Browser Plugin does not promt for proxy authentication

I have successfully configured my SWT Browser application to use the proxy by setting VM arguments -Dnetwork.proxy_host and -Dnetwork.proxy_port to the according values.
However the proxy needs authentication, but the username / password prompt does not open. Futhermore when registering an authentication listener, the listener is never triggered.
The problems occured with a Linux Debian 64 Bit distribution. When compiling the same application for windows, all works fine, i.e. the password promt opens. The SWT Browser is configured to use MOZILLA, not WEBKIT. Unfortunatelly I cannot test with WEBKIT as I am limited to a given environment.
Temp solution: When starting the Linux Mozilla Browser, the prompt comes up. If entering there correct values and afterwards starting the SWT Browser application, then no authentication is needed at all and internet access is possible. But this is not a good solution.
When I register a location listener with "addLocationListener" to look whats going on with url calls, then I can see that the initial url (for example www.google.de) results to call a certain http site of the proxy server. And this http site is a redirect to a https site of the proxy. Then the https site results in calling the http redirect page again. This is then an endless loop.
I would guess that somewhere in the JAVA code of the SWT Browser class there is a routine that calls setUrl with those pages (what results in an
endless loop) and skip to call any authentication listener for some reason.
Maybe someone has an idea whats going wrong in this authentication process?
I have no solution but a hint: I'm not sure what you mean by "Linux Mozilla Browser" - I know Firefox and Xulrunner. But your workaround suggests that profile information is shared somehow and that shouldn't happen.
I tried to find some information how to define the profile (where the web browser keeps its cache, config, SSL certificates, plugins, ...) but to no avail.
This entry in the FAQ shows how to set the proxy host: How do I set a proxy for the Browser to use?
Try to find a way to add the user/password information into the request sent to the proxy server. If that fails, create a local proxy which connects to the real proxy as upstream and which can authenticate itself.
Looking at the bug database, there is no support for Browser profiles: Flexible Mozilla profile support - new API request

Are there any samples/tutorials which tells how to call servlets on J2EE server from iPhone app?

Sorry for posting basic question but please give me your advise.
I have to write iOS application which communicates with web application deployed on Tomcat server.
The web application requires client-app to call the "logon" servlet with username and password to get JSESSIONID. Once client get JSESSIONID, the web application allows to invoke other servlets.
But I couldn't figure out how to manage the session to invoke these servlets.
Would you please introduce me the examples/tutorials to learn how to invoke these kind of servlets?
Thank you in advance.
Here's a decent example of making an http request from iOS:
iOS: How to make a secure HTTPS connection to pass credentials?
There's nothing magic about making the call to a j2ee tomcat server - it's just an HTTP request, so any way you can make an HTTP request will work for you.
Maybe this one too:
Can I make POST or GET requests from an iphone application?
edit: ahh, looks like this is the one you want:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html
The JSESSIONID is nothing special. If your application is set up to handle cookies coming back from your HTTP request then the JSESSIONID will come back as a cookie in the header. Otherwise you will be issued a redirect to a URL with the JSESSIONID in it. From there, if you handle cookies, the JSESSIONID will be passed automatically with each request with all of the other cookies. Otherwise you'll have to put it into the URL of each request manually.
Download the liveheaders plugin for Firefox and try hitting your servlet with the webbrowser and you can see how the JSESSIONID gets passed around. Next, turn off cookies in Firefox and you can see how it's passed around in the URL and you can see the redirect that Tomcat issues if you watch the headers in liveheaders.