When I configure
spring.cloud.config.server.prefix=cloud-config
I can't run Spring Cloud client without next configuration on server side
eureka.instance.metadataMap.configPath=${spring.cloud.config.server.prefix}
Spring Cloud 2021.0.1, Spring Boot 2.6.6, Eureka Service Discovery.
When spring.cloud.config.server.prefix is configured, conf file available by URL: /cloud-config/app-name/default/master. But without eureka.instance.metadataMap.configPath client try to get it's conf from this URL '/app-name/default/master'.
I found on client side that 'org.springframework.cloud.config.client.ConfigServerInstanceMonitor:105' checks configPath metadata property.
I read the doc, but it says
if the Config Server has a context path, you can set configPath
but I can't understand exactly what is the "Config Server has a context path"? Is it means server.servlet.context-path?
My question is: should I counfigure configPath when prefix is set?
Related
I can't find a way to figure out where is the host name configuration provided for the SPA application to connect to.
The command passed into the application from ASP.NET Core server while running the SPA is
ng serve --port 44472 --ssl --ssl-cert %APPDATA%\ASP.NET\https\%npm_package_name%.pem --ssl-key %APPDATA%\ASP.NET\https\%npm_package_name%.key
And I could not find any of the above strings localhost:7219, or 5219, or 7219 in the ClientApp / ClientApp/src folder (7219 and 5219 are the server ports and 44472 is the client npm port).
Do the server URLs passed from launchSettings.json asp project directly?
If so, if there a way to configure the server URLs directly from ClientApp if the client application is run from a different host, other than localhost (any where the settings (are | should be) stored)?
I can see the #Injected service everywhere but where does it store the settings is unclear (for how to configure this injected BASE_URL?):
constructor(http: HttpClient, #Inject('BASE_URL') baseUrl: string) {
http.get<WeatherForecast[]>(baseUrl + 'weatherforecast').subscribe((result : any) => {
this.forecasts = result;
}, (error : any) => console.error(error));
}
The derived question is: should by default the client Bearer authorization also work for a remote host?
The remote host for example is github pages. How to properly set the remote host configuration within client application for a particular webpack deployment with angular-cli-ghpages if the CORS hosts are configured within Program.cs? Should the client configuration for a remote host (apart from localhost) or server CORS configuration, include additional "Bearer-Cors" configuration (as for the certificate npm start script mentioned in the question above – should it be just skipped without any parameters passed in it)?
Are there any comprehensive guidelines on this subject?
Half of the answer to this question is that the template uses proxy config, which is described here https://angular.io/guide/build#proxying-to-a-backend-server and stores the configuration in proxy.conf.js within ClientApp folder. I will try to extend my answer with any found information in the future.
Update: The second part of the answer is to add the Cookie.SameSite = SameSiteMode.None; cookie authorization configuration in Startup.cs / Program.cs. Take a look at the solution: https://stackoverflow.com/a/75239406/6897369
I created spring config server with s3 backend as it described here:
https://cloud.spring.io/spring-cloud-config/reference/html/#_aws_s3_backend
I created 4 files in my-config-server s3 bucket:
app-default.properties
app-dev.properties
client-app-default.properties
client-app-dev.properties
When I ran client-app application with dev profile, I got only client-app-dev.properties properties.
I am interested if it is possible to get also client-app-default.properties, app-dev.properties and app-default.properties properties, if its were not defined in client-app-dev.properties
In another words, Is it possible to support following hierarchic:
application.properties # Applicable for all environments.
application-dev.properties # Environment level commons across all services.
client-app-dev.properties # Overrides specific to the service for one environment.
client-app2-dev.properties
for example:
client-app-dev.properties
my.property1="my-propertyDev1"
client-app-default.properties
my.property1="my-propertyDefault1"
my.property2="my-property2Default"
app-default.properties
my.property3="my-propertyAppDefault3"
when I am running client-app application with dev profile I what to get:
#Value("${my.property1}")
private String property1; //"my-propertyDev1"
#Value("${my.property2}")
private String property2; //"my-property2Default"
#Value("${my.property3}")
private String property3; //"my-propertyAppDefault3"
It works so with regular spring config server but I didn't succeed with s3 backed. It goes directly to specific app and specific profile
I have the following code based on the docs...
#Controller
#RequestMapping("neptune")
public class NeptuneEndpoint {
#GetMapping("")
#ResponseBody
public String test(){
Cluster.Builder builder = Cluster.build();
builder.addContactPoint("...endpoint...");
builder.port(8182);
Cluster cluster = builder.create();
GraphTraversalSource g = EmptyGraph.instance()
.traversal()
.withRemote(
DriverRemoteConnection.using(cluster)
);
GraphTraversal t = g.V().limit(2).valueMap();
t.forEachRemaining(
e -> System.out.println(e)
);
cluster.close();
return "Neptune Up";
}
}
But when I try to run I get ...
java.util.concurrent.TimeoutException: Timed out while waiting for an available host - check the client configuration and connectivity to the server if this message persists
Also how would I add Secret key from AWS IAM account?
Neptune doesn't allow you to connect to the db instance from your local machine. You can only connect to Neptune via an EC2 inside the same VPC as Neptune (aws documentation).
Try making a runnable jar of this code and run it inside an ec2, the code should work fine. If you're trying to debug something from your local system, then use PuTTY instance tunneling to connect to ec2 which then will be forwarded to neptune cluster.
Have you created an instance with IAM auth enabled?
If yes, you will have to sign your request using SigV4. More information (and examples) on how to connect using SigV4 is available at https://docs.aws.amazon.com/neptune/latest/userguide/iam-auth-connecting-gremlin-java.html
The examples given in the documentation above also contain information on how to use your IAM credentials to connect to a Neptune cluster.
I just had the same issue and the root cause was a dependency version conflict with Netty which is unfortunately a very pervasive dependency. Gremlin 3.3.2 uses io.netty/netty-all version 4.0.56.Final. You might find your project depends on another Netty jar such as io.netty/netty or io.netty/netty-handler both of which can cause issues so you will need to excluded them from other dependencies in your POM or use managed-dependencies to set a project level Netty version.
Another option is to use a AWS SigV4 signing proxy that acts as a bridge between Neptune and your local development environment. One of these proxies is https://github.com/monken/aws4-proxy
npm install --global aws4-proxy
# have your credentials exported as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
aws4-proxy --service neptune-db --endpoint cluster-die4eenu.cluster-eede5pho.eu-west-1.neptune.amazonaws.com --region eu-west-1
wscat localhost:3000/gremlin
Refer this
Note: You need to be in the same VPC to access Neptune cluster.
I have configured cluster with two instances on glassfish 3.1.1 and iPlanet Web Server as a load-balancer (on the same machine). For test application provided with glassfish everything works ok (and this application has session replication enabled).
But when I try to make my own application working following situation takes place: it responds when I send requests on ports of a particular instances (that is 28080 and 28081), but when I try to send request through load balancer (port 81) I get error 404. My application has not session replication enabled yet, but it can just make a connection and create two other sessions for each instance. I would like to get similar effect with load balancer.
So I would like to determine:
Is session replication strongly required to load balancer works fine?
Does anyone know any other reasons of this error?
Message from iPlanet log:
[23/Aug/2012:05:44:16] failure ( 4120) myHost: for host 127.0.0.1 trying to GET /myApp/login.jsp, service-j2ee reports: PWC6117: File "c:/webserver7/https-myHost/docs/myApp/login.jsp" not found
Additional conclusions:
(81 - http-listener port on iPlanet)
When I send GET http://localhost:81/testApp then loadbalancer passes it to glassfish and returns correct site. But when I try the same with my test application, GET http://localhost:81/myApp then iPlanet looks for this site in its own resources (docs directory as in log above)
fragment of myHost-obj.conf:
<Object name="default">
AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
NameTrans fn="name-trans-passthrough" name="lbplugin" config-file="C:/WebServer7/https-myHost/config/loadbalancer.xml"
NameTrans fn="assign-name" name="perf" from="/.perf"
NameTrans fn="ntrans-j2ee" name="j2ee"
NameTrans fn="pfx2dir" from="/mc-icons" dir="C:/WebServer7/lib/icons" name="es-internal"
PathCheck fn="uri-clean"
PathCheck fn="check-acl" acl="default"
PathCheck fn="find-pathinfo"
PathCheck fn="find-index-j2ee"
PathCheck fn="find-index" index-names="index.html,home.html,index.jsp"
ObjectType fn="type-j2ee"
ObjectType fn="type-by-extension"
ObjectType fn="force-type" type="text/plain"
Service method="(GET|HEAD)" type="magnus-internal/directory" fn="index-common"
Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file"
Service method="TRACE" fn="service-trace"
Error fn="error-j2ee"
AddLog fn="flex-log"
</Object>
First, if you are running the Load Balancer plugin, then you may have a support contract (a GlassFish license is required before you put the plugin into production). If so, calling support is a good option.
To answer your first question, session replication is not required for the Load Balancer to work.
As a shameless plug, I have a 5-part youtube series on setting this up. You can skip the videos on downloading and installing and go straight to setup/configuration/testing. Based on what you describe, I suspect the issue isn't the plugin itself, but the loadbalancer.xml configuration. Look at loadbalancer.xml and see if myApp is configured.
Hope this helps.
I'm using jboss remoting 2.5.4.SP3 to provide remote access to EJBs in a JBoss 7.1 server from both a web app and other JBoss instances. I'm doing it manually because of issues with remote EJB access in JBoss 7.1, specifically (but not only) the inability to access the same (interface) bean on multiple servers simultaneously. I'm using remoting2 because remoting3 has no documentation.
I have remoting working using TransporterHandle/TransporterClient using the socket transport, but in methods called via this remote connection, the server wants to lookup the principal from the ejbContext. I can't find a way to manually set the principal, or other contextual security/identity information. At the limit I'd be happy just to set the principal when the ejb method is invoked - all incoming calls are to local EJB3 beans - or even to set it specifically for the EJBContext.
I've found a lot of information regarding Spring (which I'm not using), but nothing seems to match my particular context.
And now, the correct way to do this:
On the client side I get the security context and package up the security domain and subject info for transport to the server along with the invocation. The SecurityDomain is a String and SubjectInfo is serializable:
Map m = new HashMap();
SecurityContext securityContext = SecurityContextAssociation.getSecurityContext();
if (securityContext != null) {
m.put("SUBJECT-INFO", securityContext.getSubjectInfo());
m.put("SECURITY-DOMAIN", securityContext.getSecurityDomain());
}
response = remotingClient.invoke(request, m);
The map m gets sent with the invocation over jboss remoting. On the server side, I extract the security information and set the context for the invocation like this:
SecurityContext oldContext = SecurityContextAssociation.getSecurityContext();
SubjectInfo si = (SubjectInfo) invocation.getRequestPayload().get("SUBJECT-INFO");
String domain = (String) invocation.getRequestPayload().get("SECURITY-DOMAIN");
if (si != null) {
SecurityContext sc = new JBossSecurityContext(domain);
sc.setSubjectInfo(si);
SecurityContextAssociation.setSecurityContext(sc);
}
try {
return super.invoke(invocation);
} finally {
SecurityContextAssociation.setSecurityContext(oldContext);
}
Works like a charm!
Have a look at the jboss-ejb-client.properties. There is also a quickstart example using a remote client to lookup an EJB.
I've solved my underlying problem, although not in the general way I was hoping for.
I put a servlet filter on all incoming requests, recording request.getUserPrincipal in a thread local. I can then access this in non-EE code and find the principal making the request. Then when I make call to my app server I use JBoss Remoting's ability to attach metadata to each invocation to pass the Principal over the wire. I had to copy the TransporterClient to do this because it's private constructors et al don't allow for overriding the functionality required to attach per-request metadata (as opposed to per-connection). On the server side I take the incoming Principal and set it into a thread local. Then, in subsequent code that accesses EJBContext.getCallerPrincipal I also lookup the incoming Principal from the thread local, and if that isn't null (hence we are in a remote EJB call), I use that if the caller principal is anonymous. If it's not anonymous then it must have been set in some way after the incoming call, so I ignore the incoming Principal in that case.
All in all, a much more specialised solution than I was hoping for, and it doesn't shed any light on how I can do generic context propagation in JBoss 7.1 over the wire.