Hi, There is a good reason to use the typeId : the identifier retrieved from a provider is unique for this provider but might exist for another provider (we could have the same identifier 1452 for Facebook and Twitter), so as we want to distinguish different users from different providers, we need a more unique identifier (FacebookProfile#1452 is indeed different from TwitterProfile#1452).
Before you go into this pull request, I'm not sure to understand why you store the id and not the typeId in your database? Thanks. Best regards, Jérôme 2014-03-26 6:09 GMT+01:00 Dinabandhu [via Shiro User] < [email protected]>: > Hi, > > I am using pac4j + buji-pac4j for cas proxying. I want to use two realms > io.buji.pac4j.ClientRealm for authentication and JDBC/JNDI realm for > authorization. > > I could not get it working because the authorization info was not being > retrieved from the jdbc realm. After some digging I found that > internalGetAuthenticationInfo in Client realm uses profile.getTypeId as the > primary principal, which is basically unqualified profile class name + # + > userId. The authorization database contains only the userId , so the jdbc > realm is not finding a match for the user. > > I found that if I change the code to use profile.getId as user id, things > work as expected. > > Temporarily we have created a realm which uses getId, as of now, but of > course we would like to get back to mainstream. > > My proposal is to create a configuration on ClientRealm, > "useTypeIdAsPrimaryPrincipal" with default value = true (current > behaviour). Setting it false will use getId as primary principal. > > I don't know the reason behind using getTypeId and whether using getId > instead won't have some bad side effect. Please let me know if this > configuration make sense and is safe. > > I will be out for more than a month, so I will try and make the change & > create a pull request before I leave. > > Please let me know if this is ok. > > Thanks & Regards, > Dinabandhu > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://shiro-user.582556.n2.nabble.com/Shiro-cas-proxying-on-multiple-realms-tp7579834.html > To start a new topic under Shiro User, email > [email protected] > To unsubscribe from Shiro User, click > here<http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=582556&code=bGVsZXVqQGdtYWlsLmNvbXw1ODI1NTZ8LTExNzY2MzcxMTY=> > . > NAML<http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-cas-proxying-on-multiple-realms-tp7579834p7579835.html Sent from the Shiro User mailing list archive at Nabble.com.
