Hi Jimmy,

As far as i know, normally yes but you can customize it according the scenario,

Can i reconfirm what kind of scenario that you want to achieve? Are these what do you want to achieve:

1. Employee resign from his job, then he try to login, he will be denied the access, or
2. Employee already logged in from his Phone in his home, he try to logged from his friend's phone, which making his Phone from his home, denied the authorization/logged off and then required that employee to re-login?, or
3. You want to do something like Temporary Login Account, after set amount of time it will auto-logged off?, or
4. User have partial control over section in App, and need to do Login with Higher managerial level account if want to accessing more control in App or simply need approval from higher ups. (which it think this is the scenario you want because you need to implement this in each viewmodel)

I will ask our AppFramework Engineer about the VerifyAsync.

Cheers,
Arief Handany

Please do ask about the VerifyAsync, because it doesn't make sense to us until explained.

The scenario is simple... a user has already logged in to mobile before, which gave him/her access to resources from the server via the web api. However, his/her account has been modified by an administrator from a user management module on a different application (e.g. a Desktop App), which connects to the same database. And since the user account had been modified (e.g. changed username/password), the account stored in a mobile device should no longer be valid.

Well, that's true... the account is no longer valid and the web api is smart enough to deny access to the user account, which is trying to access data using an outdated credentials from a mobile device. But our concern is the ability of the Crosslight framework to respond to these kind of scenarios. Simple enough that it should require the user to re-login from the mobile device, instead of showing the "Authorization has been denied for this request." error message everytime the app tries to access data from the server. And besides, the account should be validated when the app starts, even when the user account is already stored in the device. Ah! Yes, we believe it does execute the VerifyAsync method at startup, but always returns true for unknown reasons.

Hi Arief,

Thanks for your response.

Yes, actually it was deliberately not implemented with anything, Our engineer reasoning is each company may go through a different process to verify their user. One of the prominent example is Banking, they may go a great length to compare each of their customer credential while Simple Apps can just mark a field in the db, which will cause re-invalidate in the code.

First off, we don't have a custom scenario here. Others may go a greater length to secure their data but we're talking simple and expected default behaviors. And besides, securing data even going through extra miles should be done on the Web API or the at back-end. The ability of the Crosslight framework to react to denial of access, that is our concern here.

Maybe in your scenario of re-login you can create new field named RequiredLogin, everytime desktop apps edits the credential the RequiredLogin become true, then in the client code, they can check the value in that Verify method, of course, by calling to server and grab the value.

Why would you do this when the client application has already been denied access? I mean, there's an authorization error message, right? It's not about what we can do, it's about how Crosslight's AppFramework should have just navigated to the login viewmodel instead of showing an error message.

Okay, to make things simpler... run your MyInventory sample based on Web API that has security features. Please make sure [Autorize] is enabled on your Web API. Run both the app from iOS and Android device and login as expected. Or from different devices... doesn't matter if they're both the same platforms. Close the app from both devices and re-open it. Now, change your password from one of the devices, then refresh the list from the other device, which contains the outdate credentials. That should throw an exception (e.g. AuthenticationException) on the device with an outdated set of credentials. This is a common scenario and should have been dealt with a default behavior.

Issue #1, while most of the processes in your security implementation has a default functionality, this one doesn't. It just returns true, without a default behavior? Why would you create a business template that doesn't have a default functionality to verify credentials using the default table structures shown here or using social login (FYI: we're not using this)? While it is true that we can override the VerifyAsync() method to customize its behavior, without a default behavior it doesn't make any sense. Enough said with that, I guess it is what it is... but we trust Intersoft wouldn't have missed this.

Issue #2, regarding the error message returned by the RestClient ("Authorization has been denied for this request") - what happens if you change your password from an iOS device and later use the app on an Android device with old credentials already stored in it? It's like the user would say "Yey, I'm in! Oh wait! There's an error." Common sense might tell the user to just logout and re-login because he knows he changed his password from an iOS device. But that is not a very good user experience. Especially for those who do not understand what the error message means. Should we expect the user to just logout from the Android device when he/she sees the error message?

We all expect that a LoginViewModel is available and that it is being used by the line of code below. Don't know what the purpose of that is. Why is it there anyway if not in used for this kind of scenarios? There is also a method called EnsureSignedIn(), but I don't believe this is implemented anywhere in a business template and we couldn't tell in which scenarios it could be useful. Maybe useful for issue #2? Kindly elaborate on this one if it's not already documented.

// Initialize the account service
this.AccountService.Initialize(typeof(LoginViewModel));

Thanks!

Hi Jimmy,

After tested your scenario, i think you got a good point there.
I already inform this to engineer and we will update both of our AppFramework (issue #1 under CROS-858) and Samples (issue #2 under CROS-859) also thank you very much for your feedback, thats really valuable! :)

Yep you can use EnsureSignIn() for issue #2 it will be navigate user to Login screen if their Account is null/logged off but please note that after authorization denied, user actually still logged in so you should add logged off function before applying EnsureSignIn()

Hope that answer your questions!

Hi Jimmy,

CROS-858 and CROS-859 already included in our July-August 2015 Sprint but i will update you if there are hotfix or updates.

Hi Jimmy,

I will ask our developer it should be on progresses right now!

Hi Jimmy,

Very sorry for late responses, CROS-858 is planned for  september including with alternate table row maybe including with other Frameworks changes.

CROS-859 is on progress and in the process of updating samples.

Hope that'll helps!

CROS-858 and CROS-859 has been added to active sprint. The ETA of Crosslight 4 Update 1 is at the end of the month of September 2015.

We'll keep you informed about the progress of CROS-893. Please stay tuned.

Hi Jimmy,

Sorry for the lack of news, the priority for CROS-858 actually low right now and maybe will be implemented with an update for Framework, i'm really suggest you to implement it yourself if you are urgently need it.

For CROS-859 (Authorization Denied) actually it is already done, as you can see, we only fix the samples, because it was very case by case. In simpleCRM case it actually very fitting and relevant and also because we already do have the function to handle it.

As you can see here is the implementation.

You may ask why we put it in CustomerList only?
Here is the explanation: List is inherited by a lot of Class that obtain data (Opportunity List, etc), if we put it in for example edit, it won't matter because user needs to navigate to list first before class.

Also, as I said before it is a case by case, sometimes there are pages that allowed and some that are authorization free.

So I hope this will help your project!