I have a Vapor 4 app which is successfully serving HTTPS requests with no issues.
I would like it to also respond to HTTP requests on a custom port number, which will be for providing some back-end control and monitoring hooks that are called by other services on the same server, and won't be publicly reachable.
When I search Google and browse the Vapor docs for how to do this, I only get results for a very old version of Vapor, using a configuration file to specify HTTP/HTTPS server and port configurations.
Does anyone know if this type of configuration be done on Vapor 4?
Cheers and thanks in advance!
No Vapor 4 cannot serve different protocols on the same port/application. The easiest way around is to run two instances of the application, one for each. Or just get the internal traffic to use HTTPS.
Another option would be to stick Nginx in front or similar
Related
New to Container Apps.
I'm trying to understand basic connectivity between services in Container Apps.
Lets say I have a web front in .Net Core and an Web API backend (.Net Core).
Without containerization, I could put the base address of my web api in my app settings of the front end to connect to the api, lets say localhost:5000 etc. Using an httpClient to do the call.
If I containerize the front end and api and deploy it to ACA, what would that look like? I think its would be like:
Ingress external for front end
Ingress internal for api
Port 80 for both front end and web api????
Or do I need to setup a base address of some sort to call the web api? Or an environment variable?
I put both ports to 80 but they cannot seem to connect.
Thanks!
In your "Without containerization" example, if your web ui is running on localhost:8080 for example, and your API is running on localhost:5000 then you'll need to enable CORS on the api. In That example, both your web ui and your api are "external". Anything you need to call from a browser is 'external'.
Internal only are for server to server communication, or microservices communicating with each other.
In your example, you'd deploy both as external apps, this will give you 2 domains https://webui.env.region.azurecontainerapps.io and https://api.env.region.azurecontainerapps.io then you will configure a CORS policy on the api app.
see this for more details
How to name health check routes among several services behind ALB?
I'm moving my API and database to AWS. Before moving I split up my monolith REST API into four services:
public API (to which apps and websites connects)
admin API (for admin web site)
messaging API (web socket server for realtime communication with apps)
workers (queue based task processors)
I'm now trying to figure out a good organisation of the routes. At first created two subdomains, api.mydomain.com and www.mydomain.com.
I directed the api subdomain to my ALB which routed traffic based on the path only, like this:
"/sockets" -> messaging-api
"/admin" -> admin-api
"/" -> public-api
Now I'm trying to implement the health check routes. I'd like to name them "/health". But the health checks needs to be directed to each target group. Since the ALB only routes based on the path I cannot have /health on more than one server.
Possible solutions:
1. Separate the services via subdomains
I could create a subdomain for each service like:
- api.mydomain.com
- sockets.mydomain.com
- admin.mydomain.com
With this setup I could have a /health in each service without collisions.
2. Separate the health check routes via naming
I could name the health check route differently for each service like:
api.mydomain.com/health-public-api
api.mydomain.com/health-messaging-api
api.mydomain.com/health-admin-api
Suggestions?
Both the above solutions seems viable, but I'd like to know if maybe one of the solutions will bite me later, when for example more services are added, or when I'll add a graphQL API later on.
edit:
I just bumped into one drawback with solution #1. My local
dev-enviromnemt is setup with a docker image for each service and
nginx for routing the requests. On top of this I use ngrok to be able
to reach the dev environment from the Internet.
I think it would be hard to solve the service separation in based on
subdomains, but I really don't need the /health routes in the dev
enviromnent, so I guess I could just pretend they are not there.
Answering my own question as documentation and possibly some input to others.
tl;dr:
I went with a third option, separating all services via the first level in the the path. The main difference from my previous structure is that my main api (aka public-api) has moved from the root to a subpath called /app. I also renamed it to app-api.
api.mydomain.com/app/..
api.mydomain.com/admin/..
api.mydomain.com/sockets/..
api.mydomain.com/auth/..
www.mydomain.com/..
This solution gives me several pros and no cons (I think).
Pros:
Easy to route request both in ALB and in local dev environment via nginx without the extra work needed for SNI
subdomains separates api vs web sites very clearly
/health routes gets unique names by default since they live under separate paths.
the apps (web and smartphones) can use a common api url (api.mydomain.com/) and still reach all services, i.e. they don't need to store several differently initialized Axios connections. No biggie, but still..
I also opted for making /health a little more future proof and standardized on the following structure in each service.
api.mydomain.com/servicename/health
api.mydomain.com/servicename/health/is-up
api.mydomain.com/servicename/health/is-ready
up = responding to requests, ready = all dependencies are connected (i.e. databases, etc)
/health returns status 200 along with a json object describing the readiness.
/health/is-up responds with 200 or nothing (i.e. not reachable at all)
/health/is-ready responds with 200 if all dependencies are ready, otherwise 500.
The target groups in AWS will use /is-ready for health checks, but for now it's the same thing as /is-up since I haven't implemented the readiness tests yet.
I am able to hit my web service with Below URL:
http://localhost:8080/projectservices/route/rest/gethealth
But I want to force the app to access REST resource using https only as:
http://localhost:8080/projectservices/route/rest/gethealth
FYI, I am using jboss wildfly 10 server.
It will be very helpful if anyone over here will let me know what are the different approaches and you can also suggest me some link to get more understanding of it. Thanks in Advance!
http vs https is not dependent on Rest webservices.
Enabling your application to be https need to be done at your server level. In your case - Jboss.
Im not familiar on how this can be done in Jboss, see if below helps:
https://docs.jboss.org/jbossweb/3.0.x/ssl-howto.html
I'm planning to build an application that will include users registration and so on.. I want to build a kind of social network application and i wonder how should I build my server and what is the right way to connect between the application and the server?
I know to build clients and servers in python and connect between them with sockets, but I realise that this is not the right way to do it in mobile applications..
someone told me I should learn something called SOA or web application server , I did not understand him so well,
I hope that you understand what I search for, thanks!
A good start is to create a REST-based backend service that exposes methods/operations via HTTP. Host the service on your server, and allow the app to communicate with the service. This service can send and receive data, typically in the JSON format, between the service and your app(s). Try looking here for some examples:
Python: https://www.sitepoint.com/building-simple-rest-api-mobile-applications/
.NET: https://learn.microsoft.com/en-us/aspnet/web-api/overview/older-versions/build-restful-apis-with-aspnet-web-api
I'm using Eclipse to develop an app that consists of an Angular 2 front end and a Java REST back end.
For the front end, I'm using the Angular CLI plugin, which starts the app by issuing an ng serve command to the CLI. This command sets up an http server on port 4200.
For the back end, I'm using an in-company framework that launches in Jetty within Eclipse in port 8088.
While both these ports are configurable, by nature of the frameworks and plugins in use, they'll always be distinct.
Authentication works via an OAuth2 service that is also deployed to port 8088, as part of the framework. This service sets a cookie which certifies the browser session as authenticated. I have verified that this service works correctly by testing it against a Swagger instance of the REST API (also running in 8088 as part of the same framework).
The problem is that when the browser is aimed at the Angular 2 app on :4200, its internal REST API requests to :8088 aren't carrying the authentication cookie. Presumably, this is because of cross-site protection.
Is there any way for the app or the framework to tell the browser that these two "sites" are actually part of the same system?
Alternatively, if I have to configure the dev browser (Chrome) to work, I can live with that too. However, I've tried the --disable-web-security --user-data-dir recommendation, but the cookie still doesn't show up on the requests.
Lastly, I have Apache installed on the dev machine. If I can set up appropriate vhosts and use it as a proxy so that the browser thinks it's all the same, that would probably work too. It would just be a matter of intercepting all /swagger and /api requests and sending them to :8088, and all forwarding all other requests to :4200. However, I've been banging my head against mod_rewrite and mod_proxy and haven't been able to come up with anything that works.
I think what you're looking for is
withCredentials = true
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials