Hi All,
How about if we create below an interface in kernal (just the interface, no
implementation) and impl by both?
public interface Authorizable {
String getName();
boolean hasPermission(String resourceUri, String action);
}
On Wed, Feb 1, 2017 at 12:56 PM, SajithAR Ariyarathna <[email protected]>
wrote:
>
>
> On Wed, Feb 1, 2017 at 5:12 PM, KasunG Gajasinghe <[email protected]> wrote:
>
>> Hi Shariq,
>>
>> On Wed, Feb 1, 2017 at 4:45 PM, Muhammed Shariq <[email protected]> wrote:
>>
>>>
>>> On Wed, Feb 1, 2017 at 1:10 AM, KasunG Gajasinghe <[email protected]>
>>> wrote:
>>>
>>>> Hi Manu,
>>>>
>>>> #1. Because UUF's #createSession function expects an instance
>>>> of org.wso2.carbon.uuf.spi.auth.User not org.wso2.carbon.identity.mgt.
>>>> User.
>>>>
>>>> But, this is actually an improvement that we need to do. UUF should
>>>> either use org.wso2.carbon.identity.mgt.User or an extended class. We
>>>> should not have two User objects. *@UUF team*, what are you thoughts
>>>> on this?
>>>>
>>>
>>> If we do this, UUF will have a dependency to identity related
>>> components, that's not a good design IMO.
>>>
>> Agree with this.
>
>>
>>
>> Carbon-identity-mgt is for Managing user identities. The User object in
>> there represents an identity. So, why do we have to maintain a separate
>> User hierarchy?
>>
> @KasunG, UUF User and IS User classes have different goals. The only thing
> UUF wants to know about the logged-in user is how to evaluate permissions
> (authorization). UUF doesn't need the actual identity of the user (e.g.
> unique user ID, claims). Also, using IS User class as the User in UUF will
> be a problem for IS as well. Because to cater UUF future requirements, IS
> has to change its User class even it doesn't comply with IS requirements.
>
> Thanks.
>
>
>> Thanks,
>> KasunG
>>
>>
>>>
>>>>
>>>> #2. The reason is to have a balance between Nashorn js code and Java
>>>> code. If we eliminate this client service class, then we have to move the
>>>> code to Nashorn js. So, this does not result in less code. Having a client
>>>> class is preferable since Java execution is faster and developers are more
>>>> familiar with that.
>>>>
>>>> On Tue, Jan 31, 2017 at 8:31 PM, Danushka Fernando <[email protected]>
>>>> wrote:
>>>>
>>>>> I guess the idea was to write an api layer for web app which will call
>>>>> backend services and get all the data and do all the processing and return
>>>>> data sets that can directly be used in the frond end / UUF application. If
>>>>> there are no security reasons, +1 to remove the Middle man.
>>>>>
>>>>> [1] https://sourcemaking.com/refactoring/smells/middle-man
>>>>>
>>>>> Thanks & Regards
>>>>> Danushka Fernando
>>>>> Senior Software Engineer
>>>>> WSO2 inc. http://wso2.com/
>>>>> Mobile : +94716332729 <071%20633%202729>
>>>>>
>>>>> On Tue, Jan 31, 2017 at 8:14 PM, Manuranga Perera <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Manuranga Perera <[email protected]>
>>>>>> Date: Tue, Jan 31, 2017 at 2:44 PM
>>>>>> Subject: Why re-write User class? Why re-wrap RealmService?
>>>>>> To: Kasun Gajasinghe <[email protected]>, Indunil Upeksha Rathnayake <
>>>>>> [email protected]>, Danushka Fernando <[email protected]>, Ayesha
>>>>>> Dissanayaka <[email protected]>
>>>>>> Cc: Kishanthan Thangarajah <[email protected]>, Rasika Perera <
>>>>>> [email protected]>, Shariq Muhammed <[email protected]>, Shan Mahanama <
>>>>>> [email protected]>, Sajith Ariyarathna <[email protected]>
>>>>>>
>>>>>>
>>>>>> 1) Why have we written org.wso2.is.portal.user.client.api.bean.UUFUser
>>>>>> instead of just reusing org.wso2.carbon.identity.mgt.User ?
>>>>>>
>>>>>>
>>>>>> 2) Even better, is there anything stopping us from directly calling
>>>>>> RealmService OSGi service from the UUF js (eg: for list users) instead
>>>>>> going through IdentityStoreClientServiceImpl wrapper.
>>>>>>
>>>>>> Less code the better.
>>>>>>
>>>>>> --
>>>>>> With regards,
>>>>>> *Manu*ranga Perera.
>>>>>>
>>>>>> phone : 071 7 70 20 50
>>>>>> mail : [email protected]
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> With regards,
>>>>>> *Manu*ranga Perera.
>>>>>>
>>>>>> phone : 071 7 70 20 50
>>>>>> mail : [email protected]
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> [email protected]
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>> [email protected]
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>>>> email: kasung AT spamfree wso2.com
>>>> linked-in: http://lk.linkedin.com/in/gajasinghe
>>>> blog: http://kasunbg.org
>>>> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [email protected]
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Shariq
>>> Associate Technical Lead
>>>
>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: http://kasunbg.org
>> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>>
>>
>
>
>
> --
> Sajith Janaprasad Ariyarathna
> Software Engineer; WSO2, Inc.; http://wso2.com/
> <https://wso2.com/signature>
>
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
--
With regards,
*Manu*ranga Perera.
phone : 071 7 70 20 50
mail : [email protected]
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
