GSoC 2018 - OAuth Module Enhancements And SMART Apps Support Project

Tags: #<Tag:0x00007f88c96267f0>

(Harsha Kumara) #61

@pkatopenmrs I quickly checked the RestfulObservationResourceProvider interface and we don’t have support to search by patient uuid in that format. We will need to add that method.

(Harsha Kumara) #62

Can you add following method to RestfulObservationResourceProvider and build the module. After that you can send a PR to FHIR module.


  • Search observation by patient id
  • @param id object containing the requested id */ @Search() public List searchObservationBypatientUuid(@RequiredParam(name = Observation.SP_PATIENT) TokenParam id) { return provider.searchObsById(id); }

(Prabodh Kotasthane) #63

Thanks @harsha89 :slight_smile:

I will add that method.

(Prabodh Kotasthane) #64

While attempting to change the existing xml-based configuration to java based configuration I found these points :

We configure different authentication providers and inject them to authentication managers by the above method.

Now, It can be seen here that we have custom filters which refer to different authentication managers (different than what that security tag refers). This makes it very complex to inject these custom filters.

  • Further, we also have this custom filter which refers to the resource server. So to inject this filter, we need to first configure our resource server.

It would result in complex code if we first configure resource server inside the inner class and then inject that into our filter, and then injecting filter to our security configuration. This seems senseless rather than having a comparatively simpler xml-based configuration.

So I think it would be better if we rely on xml-based configuration only which gives a less complex and more clear idea about all the stuff.

cc : @mavrk

(Sanatt Abrol) #65

Fair enough @pkatopenmrs and what about the other parts of the config? I don’t think there should be any conflicts in migrating them to Annotations.

(Prabodh Kotasthane) #66

I wrote the other non conflicting parts of the configuration with annotations. But what I found was that one authentication manager(for example this) is been used multiple times due to which we have to keep it in both xml-based and annotation based configurations which in turns leads to redundant code for the same beans.

Then I read about in what places is the annotation based configuration really useful and I found that for injecting beans and complex http security configurations, xml-based configuration is much simpler and efficient.

For now, I think xml-based configuration is what best we can have? I can move to the other deliverables and afterwards we can figure out if anything better can be done with the configuration !?