Yes, you can use the same app for reference
I think it’ll be more apt if you add it under Admin page of OAuth module since we need to provide this functionality only to users who have installed the application. Look at https://github.com/mavrk/openmrs-module-oauth2-prototype/blob/oauth2-pure-rest/omod/src/main/java/org/openmrs/module/oauth2/extension/html/AdminList.java this file controls what is displayed under Admin section. You’ll also need to modify the related jsp files.
Here only the list of modules will be displayed, so “SMART application management” should be replaced with the oauth2 module title. As you can see here https://github.com/mavrk/openmrs-module-oauth2-prototype/blob/oauth2-pure-rest/omod/src/main/java/org/openmrs/module/oauth2/extension/html/AdminList.java#L39
Thank you 
yes now i got that will surely give it a thought about what and how exactly the UI needs to be changed.
Thanks for all your support
Also, include a UI mockup of what looks like when user clicks on “Run a registered application” and “Register a SMART application”. You can see https://wiki.openmrs.org/display/docs/Smart+Container+Module for reference.
ohk 
Hey @mavrk, I went through the SMART Container module link.
What i think is that we should add the “Manage SMART app” ui to the main admin page. Yes, the SMART app functionality will be only available to the users who are running the OAuth module (as it should be 
).
What we can do is, we can have an option of enable and disable the registered SMART apps. Yes the administrator has the explicit rights over it. As well as when the OAuth module is not running, implicitly all the registered SMART apps will be disabled
Because basically SMART apps do use OAuth module as a filter to access the FHIR resources, but actually they are an asset to OpenMRS, right?!
Make a proposal showing the event flow of what you are trying to make and submit it as a draft. I can only understand what you are suggesting if there’s proper research done over it. In my opinion, the ability to run or register SMART applications should be under the OAuth2 module. And if the OAuth2 module is not installed, there should be no SMART functionality. You can have the administrator to register SMART applications but a non-super user (such as a doctor) should also have the ability to run the SMART app.
Can you please elaborate what do you mean as an asset to OpenMRS?
I mean that yes, SMART apps do use OAuth 2.0 for secure authorization but the functionality of EHR launch flow suggest that we must be able to start the app from OpenMRS session and yes the EHR launch sequence surely uses the OAuth module, but the feature of launching the app isn’t a OAuth module feature. I mean the feature must be present somewhere on the main admin page.
I took a reference from the UI mock up here.
Yes I agree on this.
Ohk I understood this too.
So for now I will make mock-up placing the UI under the OAuth module title
If you still find this relevant and doable then please guide me for how can we do this
Regards 
There’s two ways we can do this
Using the already made smart-app container In this way you can create a dependency for OAuth2 module in the smart-app container. So, you’ll need to have OAuth2 module installed in-order to use the smart-app container. And we can modify the smart-app container to fulfill our needs.
Creating smart as an additional feature in OAuth2 module itself. In this approach, you can do it the way you are suggesting i.e. by adding SMART functionality to the made admin page (As you did in the UI mockup you posted above)
If you pick approach 1, you’ll have to do some more research on smart-app container. The main advantage of doing this is the modularity it provides to the end user for eg. If you don’t want to run SMART apps you can install only the OAuth2 module. However, if the user wants to run the SMART apps as well, he/she needs to install both the SMART application container as well as the OAuth2 module. Also, much of the work with UI and on the database level is already done in the smart container.
So I’d recommend that you do a thorough research on the smart container first before deciding what approach you want to use.
I am planning to go for the second approach as i went through the SMART app container and found that UI changes needs be made in it. As well as i am finding it more convenient to integrate the feature under the OAuth module. Though i think it would be helpful for me to have a look at the work done at the database level in the container to get an idea about how we can implement in the OAuth module
Thank you for your kind response and help
I have included a probable UI mock up in my proposal and will be uploading a draft in some time
Regards
I have shared the draft proposal. Feel free to give feedback.
You need to give write access for the doc you submitted so that I can review it 
Hey @mavrk, I was just going through the code and found here “realmName”. Can you explain me what exactly it is, i searched it but it didn’t clicked me much. And why is it the same , i.e. “openmrs/client” for both, client and user, AuthenticationEntryPoints ??
For the database level implementations, I have the following plan:
Quoting some lines from here :
No matter how an app registers with an EHR’s authorization service, at registration time every SMART app must:
- Register one or more fixed, fully-specified launch URL(s) with the EHR’s authorization server
- Register one or more, fixed, fully-specified redirect_uri(s) with the EHR’s authorization server
Whenever we register a new SMART app, we have to register a new client which will store the information about the SMART application either provided in a manifest.json file or entered manually (I will make the necessary UI changes in the mock-up).
I went through the present database structure of the module. Here we do have to store the launch URL of the SMART app and i am confused whether this launch URL stored as “website” for a client would serve our purpose or not.
If not then we would probably need a table “oauth_smart_app” which would have id(integer), client_id(integer) and launch_url(varchar) as the columns because the other info will be stored in the client related tables.
We would need one more table “oauth_smart_app_launch” which would have smart_app_id(integer), launch_value(varchar) and date_created(datetime) as the columns.
I think addition of these two tables would serve our purpose.
Each time a user runs a SMART app, we create launch parameter which would be of this format stored with a date and time stamp in the above mentioned table.
At the time of authorization, we can match the launch value received with one stored in the database for the respective app. After successful(or even unsuccessful ) match we can erase that launch value from database as there is no longer a purpose to save it.
Can we do it this way?
Hello @pkatopenmrs realName is nothing but an identifier which points to a particular set of groups of users which are allowed to access the associated web service. For eg. we can have users with different roles and groups of properties wanting to use our web application. Using realName, we can differentiate which services we can provide to which user group.
You can read more about it here : https://docs.oracle.com/javaee/5/tutorial/doc/bnbxj.html#bnbxm
I don’t recommend this approach because you won’t be able to tell the difference between a SMART app and an OAuth client this way.
Yes we can do this way but remember it’ll be smart_id instead of id.
Yes, we can do it this way.
Well if you plan to delete it from the database then we can do without additional column for timestamp.
yep thank you