I have following configuration on server side:
server:
port: 8888
spring:
profiles:
active: native
cloud:
config:
server:
native:
search-locations: "classpath:/config"
security:
user:
name: test
password: test
And following configuration on client side:
spring:
cloud:
config:
fail-fast: true
profile: "${spring.profiles.active}"
uri: "${SPRING_CLOUD_CONFIG_URI:http://localhost:8888/}"
username: test
password: test
I can successfully access properties from browser using user/pwd as test/test, but when my client tries to fetch it failed with 401 error:
INFO 7620 --- [5cee934b64bfd92] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://localhost:8888
WARN 7620 --- [5cee934b64bfd92] c.c.c.ConfigServicePropertySourceLocator : Could not locate PropertySource: 401 null
I tried setting the log level for spring cloud to DEBUG but nothing additional got logged, so I have no clue why I'm getting a 401 from client while I can access properties successfully via browser using the same credentials.
I've also tried removing the security from server and client and it worked perfectly, which means rest of the configurations are quite ok. But then the question is, what am I overlooking when I apply basic security and why it is not working and throwing a 401 instead?
Try checking these configurations:
spring.cloud.config.username
spring.cloud.config.password
Both properties should be defined at bootstrap.properties (not application.properties)
Please check if the way you are specifying profile name is correct and if it is getting resolved properly in Java code. You can implement CommandLineRunner and print active profiles from Environment variable.
If you specified property spring.profiles.active as native in pom.xml, you can resolve it in application/yaml file as #spring.profiles.active#
If you specified property file as VM argument, then it should work with current implementation.
If you did not specify spring.profiles.active in pom or VM argument, it will resolve to default profile, not native profile. Profile in config client and config server should be same.
Yes we have to use bootstrap properties because When the Spring Cloud application starts, it creates a bootstrap context. The bootstrap context is searching for a bootstrap.properties or a bootstrap.yaml file, whereas the application context is searching for an application.properties or an application.yaml file. The bootstrap context is the parent context for the main application
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 have 5 profiles for my Spring Boot application
application.yml
application-prod.yml
application-stg.yml
application-dev.yml
application-local.yml
One default config and 4 for different environments.
application.yml looks like this
spring:
cloud:
vault:
enabled: ${VAULT_ENABLED:false}
host: ${VAULT_HOST}
port: ${VAULT_PORT}
authentication: aws_iam
aws-iam:
role: ${VAULT_POLICY}
server-name: ${VAULT_HOST}
kv:
backend: kv
enabled: true
Some of the properties are provided by the host in the environment variables.
To support local development I am overriding authentication in local profile like this
spring:
cloud:
vault:
enabled: true
authentication: token
token: ${VAULT_TOKEN}
Now the question is how to import config correctly?
If I will do spring.config.import: "vault:" in application.yml it will fail while running with local profile. As ConfigData API will try to resolve vault properties immediately after default profile is processed (but auth info not yet loaded). But as local profile is supposed to use different auth method, it cannot access Vault and fails.
Another question is how to disable Vault in some cases? I could do spring.cloud.vault.enabled=false, but this again would cause failure as ConfigData cannot resolve vault:.
Yes I could use legacy bootstrap mode which would work fine for my scenario, but in the longer run wouldn't be ideal...
Only thing that comes on my mind is to create additional profile, eg vault which would be loaded as a last one. With enabling / disabling this profile I could control if config from Vault is imported or not...
Any other ideas?
We have the same problem, but we have found a workaround overriding the default import order of Spring Boot by importing also the profile-specific configuration files explicitly using spring.config.import in application.yml like this:
spring:
profiles:
active: ${STAGE:local}
config:
import:
- optional:classpath:application-${STAGE:local}.yml
- vault://secret/our-secret
Note that the STAGE environment variable corresponds to the profile used per stage. We made the import of the profile-specific configuration file optional, as we don't have a dedicated file for every stage.
By providing the import for the profile-specific configuration files explicitly before the vault config, we can override the default vault settings before the vault is accessed.
Still, this approach feels a bit awkward, but it's the only way so far we found to work around the issue, so better solutions would be appreciated.
I am trying the learn OpenShift Origin, and was going through the Getting Started example. I did all steps prior to creating a new application that combines a builder image for Node.js. I can see I have configured the docker registry using oc adm registry.
But in the build logs I see an error as
Pushing image 172.30.134.94:5000/test/nodejs-ex:latest ...
Registry server Address:
Registry server User Name: serviceaccount
Registry server Email: serviceaccount#example.org
Registry server Password: <>
error: build error: Failed to push image: Get https://172.30.134.94:5000/v1/_ping: http: server gave HTTP response to HTTPS client
and the build fails.
What could be the possible issue. Is it some port I have not opened or something? I would really appreciate if someone can share some insight on this and on what I may be doing wrong to get things to work
Thanks
There was a fault in the setting up of insecure registries. Fixed it and things started working.
I'm trying to set up the user mapping on SonarQube (Latest) so it can fetch the organizational structure from LDAP.
I already installed the LDAP plugin on Sonar (1.5.1), and created a minimal configuration to connect the two:
# General Configuration
sonar.security.realm=LDAP
ldap.url=ldap://ldap:389
# User Mapping
ldap.user.baseDn=ou=users,ou=udd,dc=example,dc=com
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={uid}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
All my users are under the example.com domain:
But then, as I try to login to Sonar using the LDAP entries I get the following error on the logs:
Error from external users provider: exception Java::OrgSonarApiUtils::SonarException: Unable to retrieve details for user dev1 in <default>
Which is pretty frustrating, since all those properties are configured on the configuration file above.
Any ideas about the source of this issue?
EDIT:
I found this when I increased the log depth to DEBUG:
2016.01.25 05:54:27 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://ldap:389, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, com.sun.jndi.ld
ap.connect.pool=true, java.naming.security.authentication=simple, java.naming.referral=follow}
2016.01.25 05:54:27 DEBUG web[o.s.p.l.LdapUsersProvider] integer expected inside {}: (&(objectClass=inetOrgPerson)(uid={uid}))
javax.naming.directory.InvalidSearchFilterException: integer expected inside {}: (&(objectClass=inetOrgPerson)(uid={uid}))
at com.sun.jndi.toolkit.dir.SearchFilter.format(SearchFilter.java:602) ~[na:1.7.0_95]
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1785) ~[na:1.7.0_95]
...
I don't see why is an integer supposed to be expected between the {}'s, and that doesn't make much sense compared to my LDAP structure.
Try to set ldap.user.request to (&(objectClass=inetOrgPerson)(uid={login}) (instead of using (uid={uid})).
Details:
The LDAP Plugin does not recognise {uid} and therefore doesn't know what to do with it. It then passes it to the LDAP javax.naming API, which chokes on this. This behaviour is made explicit at SonarQube startup (logs in my case):
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=cn=employees,dc=example,dc=org, request=(&(objectClass=inetOrgPerson)(uid={uid})), realNameAttribute=cn, emailAttribute=mail}
Using {login} instead (keyword shown in the documented default values) will let the LDAP Plugin build a well-formed request with a {0}:
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=cn=employees,dc=example,dc=org, request=(&(objectClass=inetOrgPerson)(uid={0})), realNameAttribute=cn, emailAttribute=mail}
The javax.naming API will then replace this {0} by a parameter which SonarQube will set to the actual username value you fill in the login form.
This is expanded version of another login module problem I had. I diagnosed some more important details which encouraged me to start new thread. It occurres that after Glassfish reboot all login modules stopped working. What is even funnier, Glassfish reports that modules where loaded correctly.
[#|2012-09-05T16:40:59.698+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmsManager;MethodName=createRealms;|Initializing configured realms from SecurityService in Domain.xml....|#]
[#|2012-09-05T16:40:59.710+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : file={glass_home}/glassfish/domains/domain1/config/admin-keyfile|#]
[#|2012-09-05T16:40:59.710+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : jaas-context=fileRealm|#]
[#|2012-09-05T16:40:59.711+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=loadKeyFile;|Reading file realm: {glass_home}/glassfish/domains/domain1/config/admin-keyfile|#]
[#|2012-09-05T16:40:59.713+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]
[#|2012-09-05T16:40:59.713+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: admin-realm|#]
[#|2012-09-05T16:40:59.714+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : file={glass_home}/glassfish/domains/domain1/config/keyfile|#]
[#|2012-09-05T16:40:59.714+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : jaas-context=fileRealm|#]
[#|2012-09-05T16:40:59.715+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=loadKeyFile;|Reading file realm: {glass_home}/glassfish/domains/domain1/config/keyfile|#]
[#|2012-09-05T16:40:59.715+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]
[#|2012-09-05T16:40:59.715+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: file|#]
[#|2012-09-05T16:40:59.717+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.|#]
[#|2012-09-05T16:40:59.718+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: certificate|#]
[#|2012-09-05T16:40:59.757+0200|FINEST|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm;MethodName=init;|JDBCRealm : jaas-context= jdbcRealm, datasource-jndi = jdbc/mysql-zus, db-user = null, digest-algorithm = MD5, encoding = Hex, charset = UTF-8|#]
[#|2012-09-05T16:40:59.758+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [ShibUserPassAuth] of classtype [com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm] successfully created.|#]
[#|2012-09-05T16:40:59.758+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: ShibUserPassAuth|#]
[#|2012-09-05T16:40:59.758+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Default realm is set to: ShibUserPassAuth|#]
[#|2012-09-05T16:40:59.762+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=1;_ThreadName=Thread-2;|SEC1011: Security Service(s) Started Successfully|#]
But I am unable to use any of secure realms, during basic authentication.
I tried both custom jdbcRealm and preconfigured fileRealm with new user
It ends up with this:
javax.security.auth.login.LoginException: No LoginModules configured for jdbcRealm
at javax.security.auth.login.LoginContext.init(LoginContext.java:273)
and this
javax.security.auth.login.LoginException: No LoginModules configured for fileRealm
at javax.security.auth.login.LoginContext.init(LoginContext.java:273)
More over I can't even use more sophisticated asadmin commands, because I received "unauthorised wrong login or password" and in server.log
No LoginModule configured for fileRealm
I checked LoginContext implementation and it looks like that
AppConfigurationEntry[] entries = config.getAppConfigurationEntry (name);
is constantly going wrong way, and null is returned.
I don't manipulate config files by hand. Can I somehow corrupt on of them in a way that block LoginModules?
Which configuration file is being read by ConfigurationEntry above?
Before this unfortunate reboot problem with the MySQL database occurred. There were more available for the Glassfish connection pool, than database permits. After killing connections from database, changing connection numbers for appropriate I rebooted container and everything collapsed.
login.conf exist in domain dir and looks ok.
Hope for help
Paraphrasing Catherine Zeta Jones and Liza Minnelli before her i will say
"and All that JAAS...".
It occurs that one of third party aplications was loading it's own login.conf file for JAAS module, which destroyed all Glassfish login modules. This situation occurs after container reboot when secondary configuration file was being loaded. Funny thing, Glassfish was able to load it's own file properly, show off in logs... and then overwrite it malicious configuration. Watch your configuration files!