what's left for release?
by Bill Burke
Where are we at? I made some minor changes to the demo examples and
subsystem that you suggested earlier as well as the theme distro changes
I made that I talked about in the previous email.
Give Marek another day to get MSSQL working? Release on Thursday?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
WildFly subsystem and demo
by Stian Thorgersen
I've just tried out deploying the demo manually using the WildFly subsystem. It's very cool and I really like how the WildFly subsystem has made things so much simpler. Some comments though on my "experience" trying this out.
1. Having to edit standalone.xml to add secure-deployment requires restarting the server. In installation tab we could have an additional option that lists the jboss-cli command to add this at runtime
2. Customer portal error messages are horrible at best. First I forgot to deploy the database services, which caused the exception "Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')". This should have probably been something like "Database services not found". Then I deployed database services, but used the wrong WAR name in the secure-deployment and the error message was the same, but should have been "Unauthorized".
3. Finally, it's not clear enough in the log output when the Keycloak sub-system acts on a deployment and when it doesn't. We definitively need something along the lines of:
INFO [org.keycloak.wildfly] Keycloak configured for 'customer-portal.war'
Could also be an idea to add (not sure if it should be info or debug):
DEBUG [org.keycloak.wildfly] Ignoring 'customer-portal.war'
12 years
initial theme feedback
by Bill Burke
Is it possible to not have the default themes stuffed in a JAR within
WEB-INF/lib and instead have them exploded within
standalone/configuration/themes? Users should be able to view, modify,
and copy them directly instead of having to download the source.
Is this just a matter of moving the theme templates out of common-themes
and removing DefaultLoginThemeProvider from
org.keycloak.freemarker.ThemeProvider file?
I can do this work if you're busy with other stuff. Do you need a
screecast created too?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
migration docs
by Bill Burke
In the docbook, there is a MigrationFromOlderVersions.xml. Please edit
this with things that may be different between alpha 1 and alpha2.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
bill rocks!
by Bill Burke
Does Viliam Rockai translate to "Bill Rocks!"?
:)
What sucks is that "Bill Berk" translates to "Bill Cunt" in British :(
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 1 month
code changes, please note
by Bill Burke
* There is no more RequireApplication and RequiredOAuthClient
credentials in the UI. They still exist in the data model and some of
the APIs but they are not expossed by the admin console.
* New Credential Type: "secret". Secrets are stored in plain text and
are the only cred type that can be retrieved from the model.
* Applications/OAuthClients are hard coded to use "secrets" as a
credential type.
* Application and OAuth Installation page has changed! It now populates
the credentials with the secret. You now also have an option to view
Wildfly/JBoss Subsystem XML that you can cut and paste.
* Application and OAuth credentials page now shows the client secret.
It also allows you to regenerate it.
* All demo code has been updated to reflect above changes.
* Installing the wildfly/as7/eap6 subsystem is now a requirement
* Demo code has changed. There are now 2 examples. preconfigured and
unconfigured that work for both AS7, EAP6, and Wildfly 8.
* We now build against WIldfly 8.0.0.Final and Undertow 1.0.0.Final.
I now need to document all this stuff and update the screencasts (as
well as document Composite roles ).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 1 month
Jenkins
by Stian Thorgersen
To make sure Keycloak works on different containers (EAP, WildFly, others?), multiple databases (MySQL, PostgreSQL, Mongo, others?) and that I don't break the build it would be great to have Jenkins setup to run tests for us.
Question is, do we rely on internal Jenkins servers (tickets, vpn, etc.) or do we use CloudBees? My personal preference is CloudBees, but if there is strong objections I don't mind either way.
Marek has experience with Jenkins so he's kindly volunteered to set this up for us (right?) ;)
12 years, 1 month
possible change to subsystem format
by Bill Burke
Old format was
<realm>
realm info
<secure-deployment name="war name">
app specific deployment
</secure-deployment
</realm>
For now, I'm getting rid of the concept of a realm. So it will just be:
<secure-deployment name="war name">
all the config you'd see in a keycloak.json file
</secure-deployment>
The benefits of this is that it will be really easy for the keycloak
admin console to initiate a deployment. Also, not sure yet, but we may
end up having an "UNCONFIGURED" mode for keycloak adapters. Where they
aren't attached to a realm/application, but are applied to the WAR
deployment (see the Aerogear hread).
The downside to this is that there will be duplicate config if there is
more than one app on the server. Later on I'll add a "realm-ref"
element or something to secure-deployment so we can define common realm
data elsewhere. I'll do that next iteration.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 1 month