Hi,
It looks as though a combination of ngx-bootstrap tooltips and raw bootstrap tooltips are being used and I'm unsure which ones we should use.
Eg: Roles and tenant settings pages use the raw bootstrap tooltips and other pages (tenant features, widgets and others) use the ngx-bootstrap.
Furthermore the ones that use the raw bootstrap ones (or at least the metronic wrapper around it). Use a strange syntax of data-toggle="tooltip" instead of data-bs-toggle="tooltip"
Further to this none of the other standard options for the bootstrap tooltip and the ones documented on the metronic site don't work either. https://preview.keenthemes.com/html/metronic/docs/base/tooltips#delay-options
Eg:
I add data-bs-delay-hide="1000" to the roles.component.html tooltip and it doesn't work. I tried with data-delay-hide as well. No good.
I also see a lot of default things being set in the metronic theme that don't get applied such as all of the following styles in the style.bundle.css
/* rtl:end:ignore */ .tooltip-inner { max-width: var(--bs-tooltip-max-width); padding: var(--bs-tooltip-padding-y) var(--bs-tooltip-padding-x); color: var(--bs-tooltip-color); text-align: center; background-color: var(--bs-tooltip-bg); border-radius: var(--bs-tooltip-border-radius); }
In particular I'm trying to configure the max-width. I've tried it using the bootstrap options to add my own custom css class (as per above doesn't work).
-bs-tooltip-max-width is set to 200px by default but if I change the title of the roles.component.html tooltip to a really long string it doesn't adhere to the max width.
Some magic appears to be going on that I couldn't find yet :)
Any tips on how we should be doing this consistently.
Thanks Rick
Yeah the RedisOnlineClientStore from ABP works well for us. Since we've switched over to it we've had no issues or problems at all.
My view is this is not a security issue. If you trace down the CheckPasswordAsync call being done here. I get into Microsoft.Extensions.IdentityCore (7.0.0.0) which is doing the password verification.
From my reading this is the code which is being used.
https://github.com/dotnet/aspnetcore/blob/53845260d1ffa1a90fe4c499142bc6709dddeacf/src/Identity/Extensions.Core/src/PasswordHasher.cs#L166
And as you can see the salt is stored in asp.net core identity with the password in the same field.
If you know the password and you copy the password column then yes you will be able to login but no this is not a security vulnerability as the password is salted and you won't be able to (easily) reverse the password from the hashed value.
Application.Current.Quit is used in I think two places in the MAUI project.
However this doesn't actually work on IOS and does nothing. There is a suggested workaround here (however not necessarily recommended).
https://learn.microsoft.com/en-us/answers/questions/1142884/how-to-close-net-maui-app-on-ios
We're working around it for now but noticed it caused a strange behaviour issue that when you say no to a retry it behaves as if you clicked yes.
Using 11.2.
When using the MAUI app, if the refresh token fails due to it being invalid then the MAUI app automatically quits and there isn't a way to recover other than to uninstall the app (or clear the app data/cache) and then you are ok.
The quit happens because UserConfigurationManager has an error handler in the call to _userConfigurationService.GetAsync
The failure looks to be in AccessTokenmanager.cs in the RefreshTokenAsync call.
The ReceiveJson section of the client triggers the AbpExceptionHandler code to run. In our case the call to the RefreshTokenAsync is returning a 500 internal server error (on the server side we can see it is a refresh token is not valid error). This then gets handled as an error. We don't see any dialogs and the code fails all the way out to the error handle in the GetAsync call at the top and quits the app.
Expected result: If the refresh token is not valid then you should just see a login screen and the _userConfigurationService.GetAsync call should be treated as if the user wasn't authenticated and there was no saved session for them.
Easiest way to reproduce it is to debug and modify the refresh token on the call such that it becomes invalid. The actual scenario we have is that we're debugging another completely random issue and switching between environments. This causes all sorts of issues with our tokens. However in prod this could become a real issue when the refresh tokens eventuall expire.
Thanks Rick
When using the MAUI app on landscape views on a tablet. There are a few issues.
See images for second item.
Thanks Rick
Hi,
Version: 12.1.0 Angular .Net Core
Having issue with scrolling on the MAUI app after you open a modal and then close it.
Steps to reproduce:
You will find that after the modal closes you cannot scroll the page any more. We have removed the virtualize component to see if that was the cause and even with a simple for loop to render the items the scrolling does not work after the modal closes.
Thanks Rick
Following on from my previous ticket.
There appears to be a lot of missing MAUI localizations (pretty much what was in the old local localization store).
For example these ones var accepted = await UserDialogsService.Instance.Confirm(L.Localize("DoYouWantToTryAgain"), L.Localize("NoInternet"));
It looks like the Xamarin local localization stuff has been missed and the error handling in MAUI has then not been checked to ensure it localizes correctly.
Thanks
Hi,
11.2 version here.
When the UserConfigurationManager GetAsync call fails in the MAUI application. Then the app get's into a state you can't recover from other than to force close the app.
The issue boils down to the fact that the localization has not yet been initialized by this API and when it fails, the webrequestexecutor exception handling is trying to use the UserDialogsService.Instance.Confirm message to display a do you want to try again message. This fails because this code itself is using localization which is not yet initialized.
So in L.cs for the MAUI app you throw an exception of "set configuration before using remote localization".
In the old Xamarin solution we had local localization which meant this didn't happen for a select few error messages.
Don't seem to have these local localizations any more and thats causing us an issue.
(The root cause of the Get call failing appears to be something wrong with the refresh token which is not being handled correctly, that I haven't investigated further yet but doing so now).
Thanks Rick
https://github.com/aspnetzero/aspnet-zero-core/issues/4757
