In which use case Multiple renderer is used in Dispatcher - aem

I am trying to understand when it make sense to use multiple renderer in dispatcher.any configuration. For example I have this setup.
On Dispatcher-1 server:
/renders {
/0001 {
/hostname "https://publish-1.com"
/port "8443"
}
/0002 {
/hostname "https://publish-2.com"
/port "8443"
}
}
On Dispatcher-2 server:
/renders {
/0001 {
/hostname "https://publish-1.com"
/port "8443"
}
/0002 {
/hostname "https://publish-2.com"
/port "8443"
}
}
Now as per my understanding dispatcher will forward the traffic to either publish-1 or publish-2 server depending on the time taken by the respective publish server.
When I look into this page then I see there is no configuration which makes it possible to direct the traffic from Dispatcher-1 to Publish-2. It is always Dispatcher-1 to Publish-1 or Dispatcher-2 to Publish-2. If Publish-2 goes down then the request landing on Dispatcher-2 will not be processed.
Could you please clarify what is the use of only one-to-one setup and when it make sense to have one-to-many setup?
Thanks for your help!

From your link
With stateful authentication, the persisted authentication state will only be available on the instance where the user is first authenticated.
This is the key. Since Publishers B & C don’t know about the authenticated request, and sessions are not shared between the application servers, all subsequent requests need to be “sticky” to Publisher A. This is maintained by the load balancer, not the dispatcher.
As a result, the dispatcher in front of Publisher A is 1:1 mapped to a single node rather than many.

Related

Milo: get IP of client

Is there a way to get a Clients IP in Context of a write?
I want to get the IP of an Client that writes to my Milo-OPCUA-Server, so I can handle these writes differently based on the Clients IP (local Clients should be able to write directly on the Server, whilst other writes should get forwarded to another Server)
Okay, this is not part of any official API right now, so it almost certainly will break in the future, but:
With the OperationContext you get when implementing AttributeManager#write(WriteContext, List<WriteValue>):
context.getSession().ifPresent(session -> {
UaStackServer stackServer = context.getServer().getServer();
if (stackServer instanceof UaTcpStackServer) {
ServerSecureChannel secureChannel = ((UaTcpStackServer) stackServer)
.getSecureChannel(session.getSecureChannelId());
Channel channel = secureChannel.attr(UaTcpStackServer.BoundChannelKey).get();
SocketAddress remoteAddress = channel.remoteAddress();
}
});
I'll have to add some official API to do this, probably something hanging off the Session object.

How to get all established connections to vertx based http server?

I have got https server run by vertx http stack. Is there a way to get client IP addresses for all established connections (i.e. for audit, security, monitoring, QoS and other purposes). Ideally, I would like to have event (callback) driven API notifying about established and closed connections. How can I achieve it?
Current workaround is to poll a tool similar to netstat, but it is very inconvenient and not really real-time (i.e. short connections can be missed).
Github community responded with the answer: https://github.com/vert-x3/vertx-web/issues/685
You can use the HttpServer connection handler and manage it yourself easily:
server.connectionHandler(conn -> {
// Track conn.remoteAddress()
conn.closeHandler(v -> {
// Cleanup track of conn.remoteAddress()
});
});
In my example I'll write all IP addresses to a console. But of course you could write it to a log file, DB, or some other place of your choice.
Vertx vertx = Vertx.vertx();
// This your regular router
Router router = Router.router(vertx);
// We'll have two routes, just for fun
router.route("/a").handler((ctx) -> {
ctx.response().end("A");
});
router.route("/b").handler((ctx) -> {
ctx.response().end("B");
});
Router filterRouter = Router.router(vertx);
filterRouter.get().handler((ctx)->{
System.out.println("IP is " + ctx.request().remoteAddress());
// Forward to your actual router
ctx.next();
});
filterRouter.mountSubRouter("/", router);
vertx.createHttpServer().requestHandler(filterRouter::accept).listen(8080);

IdentityServer3 PublicOrigin and IssuerUri Difference and Usage in IdentityServerOptions

I got some issue when deploying to IIS. Apparently the client uses reverse proxy and all of the OpenId configuration disco showing IP address instead of their domain name. PublicOrigin solves my problem. However, I still don't understand the different between,
PublicOrigin
and
IssuerUri
Example in:
var options = new IdentityServerOptions
{
PublicOrigin = "https://myids/project1/",
IssuerUri = "https://myids/project1/",
...
}
I can see from the disco showing changes as well if both value updated respectively, i.e.;
{
"issuer": "https://myids/project1/",
"jwks_uri": "https://myids/project1/.well-known/jwks",
"authorization_endpoint": "https://myids/project1/connect/authorize",
"token_endpoint": "https://myids/project1/connect/token",
"userinfo_endpoint": "https://myids/project1/connect/userinfo",
"end_session_endpoint": "https://myids/project1/connect/endsession",
"check_session_iframe": "https://myids/project1/connect/checksession",
"revocation_endpoint": "https://myids/project1/connect/revocation",
"introspection_endpoint": "https://myids/project1/connect/introspect",
...
}
and why not just make it the same as IssuerUri. I have read the documentation on this. Technically is just a description of the properties. I would like to understand more.
Many thanks.
IssuerUri is unique identifier of the authorization server. Value of this property is embedded into ID tokens in the iss property and it is during token validation.
On the other side, PublicOrigin is just a public URI of the server. If the server is behind reverse proxy, then without this hint it would advertise private URI in OpenID Connect metadata (.well-known/openid-configuration).
Why not have just single property? OpenID Connect specification (§ 16.15. Issuer Identifier) supports multiple issuers residing on the same host and port. However the same section in specification recommends to host only a single issuer per host and port (i.e. single-tenant).
When would you use multi-tenant architecture? Suppose you want to build and sell your own Authentication-as-a-Service. Now you have two options - assign dedicated URI (PublicOrigin) to each of your customers or use single PublicOrigin with dedicated IssuerUri for each customer.

How to limit the number of actors of a particular type?

I've created an actor to send messages to a chat server. However, the chat server only permits 5 connections per user. If I hammer my scala server I get error messages because my chat clients get disconnected.
So how can I configure akka so that my XmppSenderActors only use a maximum of 5 threads? I don't want to restrict the rest of the actor system, only this object (at the path /XmppSenderActor/).
I'm trying this config since I think it's the dispatcher I need to configure, but I'm not sure:
akka.actor.deployment {
/XmppSenderActor {
dispatcher = xmpp-dispatcher
}
xmpp-dispatcher {
fork-join-executor.parallelism-min = 2
fork-join-executor.parallelism-max = 3
}
}
This gives me an error though: akka.ConfigurationException: Dispatcher [xmpp-dispatcher] not configured for path akka://sangria-server/user/XmppSenderActor
I would probably try to configure a Router instead.
http://doc.akka.io/docs/akka/2.0/scala/routing.html
A dispatcher seems to deal with sending messages to the inbox rather than the actual number or Actor targets.
That configuration in particular could work for you:
akka.actor.deployment {
/router {
router = round-robin
nr-of-instances = 5
}
}
The nr-of-instances will create 5 childrens from the get going and therefore fill your needs.
You might need to find the right Router implementation though.

Knowing from which udp socket the Radius request came. Using FreeRadius

I know the question isn't very well. Sorry my english.
I want to setup a (one instance of) FreeRadius server to listen to several ports (with a bunch of 'listen' sections) and then pass the that udp port as a parameter along with User-Name and User-Password to a script that I want to use to make the authentication.
The basic idea is make some kind of domain separation. Some Firewall use radius port 2000 to make authentication. Some other different firewall (with a different set of users) use radius port 2020, for example. At the end, all the request fall in the same script that has the knowledge of both set of users and use one or the other according to the given extra attribute (port number)
I know that is possible making a virtual server per 'domain'. but I prefer not to replicate configuration files. and i think is shorter to add a little 'listen' section for every domain I want.
I tried to add an atribute this way:
listen {
ipaddr = *
port = 0
type = auth
update control {
Login-TCP-Port = 1812
}
}
and tried to read it:
autorize {
if ("%{User-Name}" == "bob") {
update reply {
Reply-Message = "This is only %{Login-TCP-Port} an example."
}
update control {
Cleartext-Password := "bob"
}
ok
}
[...]
}
But don't work.
How can i make it right?
Is this posible?
Hope you can help me.
I'm answering myself. I found (looking a like further on google) that the Packet-Dst-Port attribute have the data that I want.
I get it from here (now that I found it, look pretty obvious :P)