Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@xgp
Copy link
Contributor

@xgp xgp commented Aug 8, 2023

updated AccuntLoader to load provider(s) and check if it is compatible with the chosen theme.

Closes #22318

…untLoader to load provider(s) and check if it is compatible with the chosen theme.
Copy link
Contributor

@ssilvert ssilvert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It strikes me that the AccountResourceProvider.useWithTheme(Theme theme) probably ends up with code that is hard-coded to a theme name?

So if you wanted your theme to change providers, you would need to rebuild the provider, right?

Maybe we should establish a convention that specifies a property in theme.properties for this.

So theme.properties would just have:
accountResourceProvider=org.myorg.MyAccountResourceProviderImpl

Then the impl would have something like:

public boolean useWithTheme(Theme theme) {
    return theme.getProperties()
               .getProperty("accountResourceProvider") == this.class.getName();
}

WDYT?

@xgp
Copy link
Contributor Author

xgp commented Aug 8, 2023

@ssilvert I was thinking a similar thing. I just updated the code to check getName and getParentName so that it would work for themes of the same name or those using it as a parent. However, yours works for both cases, so I think it's better. I'll make the change.

@xgp
Copy link
Contributor Author

xgp commented Aug 8, 2023

@ssilvert updated it to be the default impl of the useWithTheme method. Still possible to override if the implementation wants something special.

Comment on lines 162 to 163
// has the flaw that it will only return the first match. no provision for multiple providers
// that match the same theme.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this as an issue. Should be fine.

@ssilvert
Copy link
Contributor

ssilvert commented Aug 9, 2023

I'm pretty happy with this and I'm looking forward to seeing the Quickstart.

@stianst What do you think? Are we missing anything? (Also see #22318)

@ssilvert ssilvert requested a review from stianst August 9, 2023 17:00
@xgp
Copy link
Contributor Author

xgp commented Aug 9, 2023

Thanks @ssilvert . For the quickstart, we were thinking of using the https://github.com/xgp/keycloak-account-v1/ repo which has an example of how to build a AccountResourceProvider and brings back the base v1 account theme. Is that an appropriate example, or do you want something simpler?

@ssilvert
Copy link
Contributor

ssilvert commented Aug 9, 2023

Thanks @ssilvert . For the quickstart, we were thinking of using the https://github.com/xgp/keycloak-account-v1/ repo which has an example of how to build a AccountResourceProvider and brings back the base v1 account theme. Is that an appropriate example, or do you want something simpler?

I think bringing back account v1 in a quickstart makes for a very good example. I was thinking that we should put the Quickstart in https://github.com/keycloak/keycloak-quickstarts. Then the tests that run against that repo would serve as a regression test for this PR.

I'm not sure what @stianst thinks about that idea. The main test suite in keycloak/keycloak ensures that this didn't break anything. It makes sense to me for a quickstart to serve as the test suite for an example provider.

@xgp
Copy link
Contributor Author

xgp commented Aug 9, 2023

Ok. I'll do a PR in https://github.com/keycloak/keycloak-quickstarts

@xgp
Copy link
Contributor Author

xgp commented Aug 17, 2023

@ssilvert quickstart done here keycloak/keycloak-quickstarts#478

@garronej
Copy link
Contributor

I can't tell both @xgp and @ssilvert just how appreciative I am for your work on this.

@xgp xgp marked this pull request as ready for review August 28, 2023 18:38
@xgp xgp requested a review from a team as a code owner August 28, 2023 18:38
Copy link
Contributor

@stianst stianst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather see the built-in provider converted to a default provider, then have the ability in the theme to select the theme provider by id. That allows directly retrieving the provider by id, instead of looping through all providers to select by class name.

Code in AccountLoader would be something like:

String accountResourceProviderId = theme.getProperty(accountResourceProvider);
accountResourceProvider accountResourceProvider = accountResourceProviderId != null ? session.getProvider(AccountResourceProvider.class, accountResourceProviderId) : session.getProvider(AccountResourceProvider.class);

A tricky thing that is needed here is we need to be able to test this stuff. Not really sure how we would achieve that as it's a bit complicated. Guess it would need a custom theme + a custom account resource provider of sorts.

One thing this doesn't cover is if there is a want to also provider custom rest endpoints, say for a completely custom SPA based account console that wants to use some custom rest endpoints. That can probably be ignored though, as it is somewhat achievable by disabling the account api feature and deploying a custom RealmResourceProvider.

@xgp
Copy link
Contributor Author

xgp commented Aug 29, 2023

I'd rather see the built-in provider converted to a default provider, then have the ability in the theme to select the theme provider by id. That allows directly retrieving the provider by id, instead of looping through all providers to select by class name.

@stianst This makes sense to me. I'll update the PR to reflect this.

One thing this doesn't cover is if there is a want to also provider custom rest endpoints

Since we are giving the extension author the ability to return a resource for /account, this technically does give them the ability to add their own custom REST endpoints under that path. However, I agree with your statement that it is somewhat moot, given that the author can also bundle a custom RealmResourceProvider to provide REST endpoints.

@xgp
Copy link
Contributor Author

xgp commented Sep 6, 2023

I made the update that makes the AccountConsole the default implementation of AccountResourceProvider.

Regarding testing, I wasn't able to find where the current account console tests are. If you can point me to those, I can write a simple custom provider and add a test.

@ssilvert
Copy link
Contributor

ssilvert commented Sep 7, 2023

I made the update that makes the AccountConsole the default implementation of AccountResourceProvider.

Regarding testing, I wasn't able to find where the current account console tests are. If you can point me to those, I can write a simple custom provider and add a test.

@xgp With your latest changes the default AccountConsole now uses the provider. So the provider mechanism is already tested by default, right?

@xgp
Copy link
Contributor Author

xgp commented Sep 7, 2023

@xgp With your latest changes the default AccountConsole now uses the provider. So the provider mechanism is already tested by default, right?

@ssilvert That's correct. So that is implicitly tested. Let me know if more needs to be done.

@ssilvert
Copy link
Contributor

@xgp What is the status of this? Is there something we are waiting on?

@xgp
Copy link
Contributor Author

xgp commented Sep 27, 2023

@ssilvert Not that I know of. I made all of the suggested changes. AFAIK it is ready.

@ssilvert
Copy link
Contributor

@xgp Oh, I didn't see your comment from two days ago. Looks like you are waiting on us.

@pedroigor @stianst I've kicked of CI. Is there anything you need to see before we merge this?

@xgp
Copy link
Contributor Author

xgp commented Sep 27, 2023

@ssilvert No problem. Let me know if anything comes up that you need me to do.

@xgp
Copy link
Contributor Author

xgp commented Sep 27, 2023

Ah. It looks like I missed pushing up one change. Just did abfc18f. My mistake

@xgp
Copy link
Contributor Author

xgp commented Sep 28, 2023

@ssilvert It looks like there are some things running in CI that I'm missing in my local testing. Is there a guide somewhere on running those same tests locally, so I can make my way through the errors? Or should I just start going through everything that gets run in the ci.yml?

I'm currently doing:

# build everything
mvn clean install -DskipTests=true
cd distribution
mvn clean install

# run testsuite for embedded
cd ..
mvn -f testsuite/integration-arquillian/pom.xml clean install

@ssilvert
Copy link
Contributor

@xgp I can see what's wrong with most of these. It's trying to go to the account console V2, which starts with an unsecured page if you hit it before login. Before logging in, go to something like http://localhost:8180/realms/master/account/ and you will see it.

On that page is a title that says, "Welcome to Keycloak account management". That's what these tests are looking for to make sure that the test is starting on the correct page.

But what is happening instead is that it is going to a login page. This likely means that the account console V2 is not active. Probably, your provider is taking over, which immediately needs a login to proceed.

So I think the fix is probably to just make sure that your provider is only active during your specific tests.

@@ -0,0 +1 @@
org.keycloak.testsuite.theme.CustomAccountResourceProviderFactory No newline at end of file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to what @ssilvert suggested.

This file should be in the same module where the custom provider is located. I think that is why the server can not find the provider at runtime. The custom providers are only resolved reading service files from JAR files deployed to the providers dir.

Here you have it in the test suite base module.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file should be org.keycloak.services.resource.AccountResourceProviderFactory.

… put custom AccountResourceProviderFactory for testing in the same project as the implementation.
@xgp
Copy link
Contributor Author

xgp commented Sep 29, 2023

@ssilvert @pedroigor Thanks for the help! I've made the changes to put the services files in the right places.

I am still struggling a bit to understand how to run the offending tests locally. I have searched around, and other than this guide I can't find great guidance. And when I try what is in the ci.yml I get a lot of failures, even when I go back and run them against main. Any suggestions here would be helpful. TY!

@pedroigor
Copy link
Contributor

Try this:

  • Build the project and skip tests
  • Run a single test
mvn -f testsuite/integration-arquillian/pom.xml clean install -Pauth-server-quarkus -Denforcer.skip -Dtest=OIDCProtocolMappersTest
  • Make sure you have auth-server-quarkus-embedded maven profile enabled in your IDE
  • Run tests from the IDE

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unreported flaky test detected, please review

@ghost
Copy link

ghost commented Oct 2, 2023

Unreported flaky test detected

If the below flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.ui.account2.DeleteAccountTest#navigationTest

Keycloak CI - Account Console IT (chrome)

org.openqa.selenium.NoSuchElementException: 
no such element: Unable to locate element: {"method":"css selector","selector":"#username"}
  (Session info: headless chrome=117.0.5938.92)
For documentation on this error, please visit: http://seleniumhq.org/exceptions/no_such_element.html
Build info: version: '3.14.0', revision: 'aacccce0', time: '2018-08-02T20:19:58.91Z'
...

Report flaky test

Copy link
Contributor

@pedroigor pedroigor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xgp Thanks.

@stianst @ssilvert LGTM. As you are the initial reviewers, waiting for your review too.

Copy link
Contributor

@ssilvert ssilvert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@stianst stianst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not clear to me how the provider is loaded when a theme doesn't define the account provider to use.

@stianst stianst self-requested a review October 5, 2023 13:03
@garronej
Copy link
Contributor

garronej commented Nov 28, 2023

Thank you all for this work on this!

Keycloakify v9 has been released and it brings back support for Account theme in Keycloak 23!

https://github.com/keycloakify/keycloakify

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow overriding Account Console resources for full control and backwards compatibility

5 participants