Language | Type | |
---|---|---|
Account | PHP | Web |
ADM | Java | Web |
AuthUtil | Java | Web |
BAM | Java | Web |
BTM | Java | Web |
calendar | Java | Web |
CNM |
<!DOCTYPE html> | |
<!-- USAGE: | |
(1) replace myserver.example.com with your keycloak server | |
(2) replace myrealm with realm | |
(3) replace myclient with cliend ID | |
--> | |
<html> | |
<head> | |
<title>Keycloak js client example</title> | |
</head> |
/** | |
* Tests that user can link federated identity with existing brokered | |
* account without prompt (KEYCLOAK-7270). | |
*/ | |
@Test | |
public void testAutoLinkAccountWithBroker() throws Exception { | |
final String originalFirstBrokerLoginFlowId = getRealm().getIdentityProviderByAlias(getProviderId()).getFirstBrokerLoginFlowId(); | |
brokerServerRule.update(new KeycloakRule.KeycloakSetup() { | |
@Override |
Jefferson Lab uses an interecpting TLS/SSL proxy server with a custom certificate so Internet access from onsite often does not work as expected. Plus, there is a very aggressive firewall on the accelerator network that blocks most everything by default.
For builds to work they often need to (1) connect to Internet and (2) trust SSL certificates. For Accelerator Internet access historically we used a proxy (deprecated, now):
setenv https_proxy jprox.jlab.org:8082
(csh)
OR
export https_proxy=https://jprox.jlab.org:8082
(bash)
In order to define user-level Gradle properties such as GitHub and BinTray tokens create a file at ~/.gradle/gradle.properties and ensure you have the environment variable GRADLE_USER_HOME (includes .gradle directory) or USER_HOME (excludes .gradle directory) defined.
This document describes how to leverage docker compose for multiple use cases while minimizing duplication of services. The use cases covered are:
Type | Use Case | Description | Command |
---|---|---|---|
Demo | Quick start demo | As easily as possible run your app (with all services it depends on) for demonstration purposes. Repeat: this case must be as painless as possible. Uses a tagged image for all containers (no Dockerfile / docker build). | docker compose up |
Test | Integration testing | Leverage CI actions / custom scripts to run integration tests. Alternatively use favorite container test framework such as testcontainers.org to run automated integration tests. In Java interfaces with JUnit; in Python usually interfaces with pytest. Most container test frameworks support launching from compose file, but often limited so may need to use framework API to defi |
This document describes how to leverage docker build for multiple use cases. The two use cases covered are:
Use Case | Description | Command |
---|---|---|
Remote Source | Build your app image in the most reproducible way possible. Repeat: this case must be painless for users and as reproducable as possible. Assumes nothing is available in your local docker build context and instead the context is fetched from a URL. This is the build to use when creating a tagged image for a repository. | docker build https://github.com/<user>/<project>.git#<tag> |
Local Source | Build your app image assuming that the local docker build context includes the source files you need. This can be convenient during development, but can be problematic in some CI environments that have different assumptions about build context. Leverages docker COPY and can potentia |