I have a vps, where my spring boot backend is running on. The frontend is a mobile app built with the ionic framework.
The backend is built this way: in the front there is an so called resource server, which is an graphql server, which redirects the requests to rest microservices which are behind the resource server. Every microservice has is own task, which he's responsible for. (e.g. an fileupload-server which uploads/downloads files to a database). The whole application, including the frontend is secured by an keycloak instance, which is running as an docker container like the whole application, except the frontend.
Now my questions is, we dont have a domain and for some reason they wont buy one, but we wont to secure the communications over ssl/lets encrypt. But lets encrypt isn't able to create ssl certificates for ip adresses. So finnaly my question is: do you guys, know a solution to my problem which fits?
So far,
Daniel
Related
Maybe someone call help me to find a solution.
I have an angular app in a different folder of my git project.
Normally i use ng serve and open the frontend on its dedicated port.
I start the spring boot app on its own port and set a CORS filter to allow it.
However now that we are testing OAUTH i would like the frontend to be served be backend.
My problem is that ng serve is in memory and i dont know what would be the best option to include them into the backend.
I have tried to build them into the backend and then rebuild with mavent but that takes way to long for every small change on the frontend.
You may use a proxy which forwards requests to APIs or UI based on the Path. Something like
http://localhost:8888/api ---> [Proxy Server (localhost:8888)] ---> Spring Boot API (http://localhost:8080
http://proxy-domain.com:proxy-port/ui ---> [Proxy Server (localhost:8888)] ----> Angular App (http://localhost:4200)
For the proxy server, you can use free tools like Fiddler and have a rule there to route based on the URL patters (/api or /ui)
We have this architecture:
Web Server: Web Application is deployed (html, javascript, css)
Application Server: WebApi is deployed
Problem is , I cannot make ajax request to reach Application Server because its behind firewall.
The Web Application is supposed to be used publicly to the internet users.
What changes should we do to make it work?
Should we move our Web Application to Application Server? But how would this be accessible on internet.
Thanks in advance for suggestions/advice.
You're going to have to put an exception in the firewall for the address of your web server... that way your web server can access the API but nothing else can (well, not quite nothing else - other stuff on that web server can but that can easily be solved by having your web app hosted on it's own/dedicated web server).
If your Web Application makes direct calls to the Web API endpoint (e.g. is a single page application that use a client-side javascript framework like AngularJS and/or it uses AJAX calls to your application server address), there is no way for your clients to access your API if you do not allow public access to your application server.
That's because your client resides inside your users web browsers.
You have to allow incoming connections to your Application Server through internet in your firewall.
Well, it all depends on how you look at things and how distributed your application should be (criteria like load, security).
In general, Web API might be just one more client (from your applications server perspective).
On the other hand, in robust/distributed system, you would have Web API only as an endpoint (controllers, mappers and things like that) that your mobile/ajax clients send requests to and then Web API communicates to Application server (where your business logic is).
Having Web API communicate to DB directly is not a good idea because as you add clients to application server (mvc, web api, services, etc...) then you have as many db access points as you have clients. So, its a code maintenance problem plus a problem of your view tier being aware of DB.
Ideally, you need Application server as a tier where all your business logic is and its the one that all your clients target (mvc web app, web api, desktop, services, etc...) and that is the one that should communicate to your DAL. Also, then you can set firewall rules on your application server to allow incoming traffic from trusted sources (your other servers) instead from the whole internet (ajax).
I am setting up an API for a mobile app (and down the line a website). I want to use oAuth 2.0 for authentication of the mobile client. To optimize my server setup, I wanted to setup an oAuth server (Lumen) separate from the API server (Laravel). Also, my db also lives on its own separate server.
My question is, if using separate servers and a package like lucadegasperi/oauth2-server-laravel do I need to have the package running on both server?
I am assuming this would be the case because the oAuth server will handle all of the authentication to get the access token and refresh access token functions. But then the API server will need to check the access token on protected endpoints.
Am I correct with the above assumptions? I have read so many different people recommending the oAuth server be separate from the API server, but I can't find any tutorials about how the multi-server dynamic works.
BONUS: I am migrating my DB from my API server, so I would assume I would need the oAuth packages migrations to be run from the API server also. Correct?
I have developed a web app that does its own user authentication and session management. I keep some data in Elasticsearch and now want to access it with Kibana.
Elasticsearch offers a RESTful web API without any authentication and Kibana is a purely browser side Javascript application that accesses Elasticsearch by direct AJAX calls. That is, there is no "Kibana server", just static HTML and Javascript.
My question is: How do I best implement common user sign on between the existing web app and Elasticsearch?
I am interested in specific Elasticsearch/Kibana solutions, but also in generic designs for single sign on to web apps and the external web APIs they use.
It seems the recommended way to secure Elasticsearch/Kibana is to have an Apache or Nginx reverse proxy in front that does SSL termination and user authentication (Basic auth). However, this doesn't play too well with the HTML form user authentication in my existing web app. Ideally I would like the user to sign on using the web app, and then be allowed direct access to the Elasticsearch API as well.
Solutions I've thought of so far:
Proxy everything in the web app: Have all calls go to the web app (server) which does the authentication, and have the web app issue the same request to the Elasticsearch web API and forward the response back to the browser.
Have the web app (server) store session info that Apache or Nginx somehow can look up and use to authorize access to the reverse proxy.
Ditch web app sign on and use basic auth for everything.
Note that this is a single installation, so I don't really need any federated SSO solutions.
My feeling is that the proxy within web app (#1) is a common generic solution, but it seems a bit heavyweight to have everything pass through the possibly slow web app, considering that Kibana uses the Elasticsearch API directly.
I haven't found an out of the box solution designed for the proxy authentication setup (#2). My idea is to have the web app store session info in memcache or the like and use some facility in the web server (Apache or Nginx) to look up the session based on a cookie and allow proxy access if authenticated.
The issue seems similar to serving static files directly using the web server (Apache or Nginx) while authenticating using a slow web app. Recommendations I've found for that are however very specific to that issue, like X-Sendfile.
You could use a sessionToken. This is a quite generic solution. Let me explain this. When the user logs in, you store a random string an pass him back to him. Each time the user tries to interact with your api you ask for the session Token you gave him. If it matches, you provide the service he is asking for, else, you just ignore his call. You should make session token expire in a certain interval of time and make a new one each time the user logs back in.
Hope this helps you.
This question is primarily for the CloudFoundry developers. Has something changed that would make a client application using spring social unable to use basic client authentication to communicate with my core application hosting an oauth2 provider? When I run the client application on a tomcat server everything works. It also worked on a cloudfoundry microinstance about 2 weeks ago. Now I get a 401 unauthorized error making a call to the service at "../oath/token" on my core application. To see what I am referring to, my application is http://www.metroseattlegamers.com If you click the "Games" link at the top it brings you to a separate application. If you sign in using the application at http://gamerepository.metroseattlegamers.com, the "sign in with metroseattlegamers account" button uses custom spring social code to communicate to my spring oauth2 provider code at http://www.metroseattlegamers.com. That all works fine because it is running on two separate tomcat servers on different machines. However, I tested and wrote everything using cloudfoundry micro instances to run client apps. As I said, it was working about a week or two weeks ago. Now I get a 401 error when I run the client on a cloudfoundry instance. Everything still works great when I run two separate tomcat servers on separate machines. Rather than include a bunch of code, I am just curious if anything has changed with how cloudfoundry microinstances work in the last week or two that may have caused this problem.
No as far as I know. Would it be possible for you to file a ticket at the official support page: http://support.cloudfoundry.com. There you can get a private agent to assist and maybe share the implementation of your app to further debug. You will need to sign in by the account you registered on www.cloudfoundry.com.