Bug in UI?
by Guus der Kinderen
Hi,
I did not try to reproduce this on master branch, but got it twice now on
1.9.x. The branch HEAD is commit b01f522acea6b6c5c6f487dc626a24ca928da77d
After I build the distribution...
$ mvn clean install -DskipTests -Pdistribution
... extract the distribution ...
$ cd /distribution/server-dist/target/
$ tar zxvf keycloak-1.9.2.Final-SNAPSHOT.tar.gz
... and start a standalone instance ...
$ cd /keycloak-1.9.2.Final-SNAPSHOT/bin
$ ./standalone.sh
... open the webpage at http://localhost:8080/auth
... create a new user
... login to the administration console with that user
... go to the list of clients
... and open (or click 'edit') on any of the clients
Then the webpage that I'm looking at appears to be broken. I'm looking at
the template itself, I think.
Is this me, or can someone reproduce this?
- Guus
8 years, 8 months
1.9.x branch updates (READ THIS!)
by Stian Thorgersen
We are not going to accept any more features, improvements or refactoring
to 1.9.x branch from now on!
Bug fixes to be included in 1.9.x will have to be approved by the holy
triangle (Bolek, Bill and myself).
The exceptions are:
* Admin CLI - additions required for testing Admin REST APIs
* Documentation - this will most likely be moved to GitBook for 1.9.3
release
* Testsuite
On-wards to 2.x (with a slight detour to Testland and Documentation City)!
8 years, 8 months
Re: [keycloak-dev] [keycloak-user] Documentation subjects - need feedback
by Bill Burke
Not sure what you mean by entitlements. User role mappings is about all
we got. Please edit the Wiki directly.
On 4/12/2016 11:06 AM, Lars Noldan wrote:
> I'd love more documentation about how entitlements are being handled
> by keycloak users, and best practices for configuring the same.
>
> On Tue, Apr 12, 2016 at 9:55 AM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> Created a wiki:
>
> https://github.com/keycloak/keycloak/wiki/Docs
>
> Please add things you want covered that are weak or non-existent in
> documentation. I'll be going through the email list as I know there
> were a number of threads on this stuff too. I'll post an outline
> sometime next week after we have a few internal meetings on the
> subject.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 8 months
Renamed package because of fuse
by Marek Posolda
Found that fuse adapter doesn't work due to adapters packaging changes.
JIRA is here: https://issues.jboss.org/browse/KEYCLOAK-2816
Among some minor things, the biggest issue is that osgi doesn't work
properly if there are 2 modules with classes inside same package. There
is "adapter-spi" and "adapter-spi-public" modules with both having
classes inside package "org.keycloak.adapters.spi". So the easiest
solution was just to rename the package.
There was possibility to rename either:
(1) the one inside "adapter-spi"
(2) or the one inside "adapter-spi-public" .
I've actually chose the (1) and renamed the one inside "adapter-spi" to
"org.keycloak.adapters.spi .internal". Only reason is that there might
be some users, who are using classes AuthenticationError or LogoutError,
so they don't need to change the code of their applications because
upgrade. On the other hand the (2) (rename the package inside
"adapter-spi-public" to "org.keycloak.adapters.spi.public" and keep the
one inside "adapter-spi" unrenamed) have the advantage of better
consistency among module names and package names. So if you rather want
me to go this way, let me know and I can change it.
For now, the PR against 1.9.x for path1 is here:
https://github.com/keycloak/keycloak/pull/2614 . There are 72 affected
files because of package renamed, but all of them are inside adapters.
Will send PR against master too if you agree with the path1. Not sure if
we rather need to retest all the examples because of the change... :-(
Marek
8 years, 8 months
Adapter Versioning
by Lance Ball
Hi all
I've been emailing with Stian about versioning in the "Node.js adapter
releases" thread, but as he pointed out, some of my concerns are broader
than just Node.js and so I am broadening the conversation a bit.
Background: I am working as part of a Node.js RHT "middleware" team to,
among other things, contribute towards the development of Node.js modules
for our existing JBoss technologies. As part of this, we're doing what we
can for the Keycloak Node.js pieces.
As it stands now, I understand that versioning of adapters must remain in
lockstep with Keycloak core. I understand the motivation for this, but want
to push back on this just a little bit, and open it up for discussion.
I see a couple of scenarios where this is potentially problematic. I am
using Node.js and NPM here, but I think the concerns should apply to any
adapter that is part of an ecosystem outside of Java.
1) There is a security flaw in some 3rd party dependency of the adapter,
discovered the day of a Keycloak core release. This renders the "latest"
version of an adapter useless until a new Keycloak server is released. I
understand that the release cadence is anticipated to be approximately
every 6 weeks (which is laudable), but still that's > 1 month that users
have to wait for a security fix.
2) There is no change in the adapter between releases of Keycloak server.
In this case, it's not necessarily a problem to release a new adapter
version, but it seems noisy and pointless if the bits are exactly the same.
When we look at version numbers, they are typically MAJOR.MINOR.PATCH with
possibly a pre-release suffix like -Alpha1. I would like to discuss the
possibility for adapters to issue patch level releases independent of a
server release. This would allow for MAJOR.MINOR versions to remain
consistent so to communicate compatibility with a given Keycloak server
version. But would provide flexibility for adapters to deal with both
issues noted above.
And just for the sake of argument, let's look at a hypothetical situation
where Keycloak is baptized a Product, and the release cadence slows down
significantly to every 12-18 months. What if a major security flaw is
discovered in an adapter? Should this trigger a new release of Keycloak
server itself? Would it not be better to allow the adapter to issue a patch
level release instead?
If you've read this far - thanks! Looking forward to your thoughts.
Lance
8 years, 8 months
robots.txt
by Thomas Raehalme
Hi!
What do you think of including robots.txt in the Keycloak distribution to
try to avoid Keycloak being indexed?
We had a nasty issue with BingPreview trying to load URLs and causing
one-time links to be invalidated.
Best regards,
Thomas
8 years, 8 months
Preventing password managers from filling password fields on forms outside login
by Stian Thorgersen
Password managers are becoming increasingly naive when it comes to filling
a form with username/password. In fact Firefox's algorithm is as simple as:
* Is there a input type=text followed by input type=password then sure it's
a login form
* autocomplete=false let's ignore that, otherwise those pesky web
developers may stop us from filling username/password
Makes sense right? Well sure it does as long as it's an actual login form.
Problems comes when it's not, for example in Keycloak:
* Admin wants to reset user credentials - Firefox enters admins own password
* Admin wants to register a identity broker - Firefox enters admins
username/password as client id/secret
* User wants to register new user - Firefox enters previously used password
* This is the best one! When admin wants to configure a authenticator and
the config type is a string Firefox enters the password into the hidden
password input, then since the visible text field and the hidden password
field share the same model Angular copies the value from the hidden
password field to the text field and no the admins password is visible in
clear text. More details in KEYCLOAK-2804.
Awesome stuff! Every form with a password field must be a login form
right?!?
Solution is simple. If you create a form that has a input type=password
then add the following to the top of the form:
<input type="text" readonly value="this is not a login form"
style="display: none;">
<input type="password" readonly value="this is not a login form"
style="display: none;">
This will make the password manager assume does fields are the
username/password fields and since they are readonly it won't fill them.
Changes to Keycloak here https://github.com/keycloak/keycloak/pull/2600.
8 years, 8 months
