On Sat, Sep 16, 2017 at 1:38 PM, Johann Nallathamby <[email protected]> wrote:
> I also have the same concerns as Hasintha. The only viable solution seems > to be Pulasthi's which is to do the HEAD call to a URL which we know that > doesn't consume much resources. If needed we can even introduce a resource > like that for this purpose if already not available. It's kind of like > having a ping service right? And also disable the client following > redirects. > If we are doing a HEAD call, we need to make sure to hostname verification configuration set at server level. Otherwise if someone wants to use our authentication endpoint they will be forced to fix certs etc. when trying with a hostname although there is flag to switch off hostname verifications. So far we only faced this situation(forced to changes certs when using with a hostname) only for dashboard logins since this HEAD was done specifically if the SP was dashboard. Now that we have enabled this for all service providers fixing the hostname verification will be important. > > On Tue, Sep 5, 2017 at 10:25 PM, Hasintha Indrajee <[email protected]> > wrote: > >> Can we alter a config inside webapp easily ? I mean if another product >> wants to change the config in order to change the OOTB behaviour, it has to >> extract and change the config at product build time. Is this >> straightforward to a config inside a webapp ? On the other hand we cannot >> move this config to a file which stays out of the webapp. It's not correct >> since authentication endpoint should be ideally self contained. >> >> On Tue, Sep 5, 2017 at 10:01 PM, Nuwandi Wickramasinghe < >> [email protected]> wrote: >> >>> >>> >>> On Tue, Sep 5, 2017 at 12:59 PM, Farasath Ahamed <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Tue, Sep 5, 2017 at 12:39 PM, Pulasthi Mahawithana < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Sep 4, 2017 at 2:44 PM, Hasintha Indrajee <[email protected]> >>>>> wrote: >>>>> >>>>>> I think we must avoid this if this is just to check whether the >>>>>> endpoint exists or not. This is anyway a costly operation. Head will only >>>>>> reduce the transport cost. Otherwise when the head request reaches back >>>>>> end, it does the relevant operation treating the request as a GET and >>>>>> avoid >>>>>> responding with actual payload. In our case this is very costly because >>>>>> within these calls, there are user store accesses and multiple other DB >>>>>> accesses. >>>>>> >>>>> >>>>> We'll need that check (or some other way) to check whether the >>>>> identity mgt webapp exists and deployed since some products don't ship it >>>>> by default. And yes, we need to get rid of calling an endpoint which does >>>>> any heavy work. So shall we do the HEAD to a page which does not do any >>>>> heavy work? May be to "accountrecoveryendpoint/error.jsp"? >>>>> >>>> >>>> Wouldn't it be easier if we do this with a config. >>>> ie. By default we do not show these links. If any product ships the >>>> account recovery endpoint and they want to show the recovery links for all >>>> service provider logins, then they override this config at product level. >>>> >>> +1 >>> Actually there is "IdentityManagementEndpointContextURL" parameter >>> configured in authenticationendpoint web.xml. Value of this parameter is >>> used to determine the recoveryendpoint url. As per the current >>> implementation, if this parameter is not configured, we retrieve the webapp >>> url by calling *IdentityUtil.getServerURL("/accountrecoveryendpoint", >>> true, true). *Can't we avoid showing the links if >>> *IdentityManagementEndpointContextURL* is not configured in >>> authentication endpoint? In the default pack, this parameter is commented >>> out. So anyone who needs it can un comment it. >>> >>> However with this implementation, the default behavior of dashboard >>> login page would change. >>> >>>> >>>> Another reason for this suggestion is that, upto IS 5.3.0 we only >>>> showed the recovery related links when login into user dashboard only. So >>>> this is essentially a change in the default behaviour of the product where >>>> we now show the recovery links in the login page for all service providers >>>> (not just the dashboard). So if someone wants to stick to the previous >>>> behaviour they should have a way to do so (ie. maintain backward >>>> compatibility). >>>> >>> >>>> >>>>> >>>>> >>>>>> >>>>>> On Fri, Aug 18, 2017 at 4:39 PM, Isura Karunaratne <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> On Fri, Aug 18, 2017 at 4:33 PM Malithi Edirisinghe < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> On Fri, Aug 18, 2017 at 4:02 PM, Isura Karunaratne <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Malithi, >>>>>>>>> >>>>>>>>> On Fri, Aug 18, 2017 at 3:41 PM, Malithi Edirisinghe < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Aug 18, 2017 at 12:31 PM, Nuwandi Wickramasinghe < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Looks like http calls are done to validate the endpoint url. Do >>>>>>>>>>> we need this validation before showing the link? >>>>>>>>>>> >>>>>>>>>>> Shall we remove these calls and directly show the hyper link? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So here the validation is done as we are invoking another webapp. >>>>>>>>>> So that this check make sure a broken link is never to be shown in >>>>>>>>>> this >>>>>>>>>> login page. Moreover, this is just a HEAD call so I don't think >>>>>>>>>> invoking >>>>>>>>>> that impacts the login page performance, because the actual page is >>>>>>>>>> not >>>>>>>>>> getting rendered here. >>>>>>>>>> The other thing is these webapps are coming from two features, so >>>>>>>>>> IMO, we cannot directly couple them together. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Is that working correctly?. I think HEAD operation returns 200 OK >>>>>>>>> for any endpoint starting with https://localhost:9443. >>>>>>>>> >>>>>>>> >>>>>>>> How can that happen ? >>>>>>>> >>>>>>> Because carbon redirects invalid urls to main page. >>>>>>> >>>>>> >>>>> This is because the http client follows the redirects by default. If >>>>> we disable following redirects at the client this check should be >>>>> possible, >>>>> and it will return a 302 if identity mgt web app doesn't exist. >>>>> >>>>>> >>>>>>> >>>>>>> We call head on the URL right. Anyway, if it's not working we should >>>>>>>> fix. >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Isura. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> On Fri, Aug 18, 2017 at 11:54 AM, Farasath Ahamed < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There is another complication here. We are not honouring the >>>>>>>>>>>> hostname verification settings set by Kernel when doing the >>>>>>>>>>>> backend call. >>>>>>>>>>>> Ideally, we should be using the common-http client if we are >>>>>>>>>>>> doing any backend https calls. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Farasath Ahamed >>>>>>>>>>>> Software Engineer, WSO2 Inc.; http://wso2.com >>>>>>>>>>>> Mobile: +94777603866 >>>>>>>>>>>> Blog: blog.farazath.com >>>>>>>>>>>> Twitter: @farazath619 <https://twitter.com/farazath619> >>>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Aug 18, 2017 at 11:45 AM, Gayan Gunawardana < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> In IS 5.4.0-m2 SSO login page we can see couple of hyper links >>>>>>>>>>>>> for Forgot Password, Forgot Username, Register Now as below. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Actually how it renders is >>>>>>>>>>>>> >>>>>>>>>>>>> <% >>>>>>>>>>>>> url = new URL(identityMgtEndpointContext + >>>>>>>>>>>>> "/recoverpassword.do?callback=" + Encode.forHtmlAttribute >>>>>>>>>>>>> (urlEncodedURL)); >>>>>>>>>>>>> httpURLConnection = (HttpURLConnection) >>>>>>>>>>>>> url.openConnection(); >>>>>>>>>>>>> httpURLConnection.setRequestMethod("HEAD"); >>>>>>>>>>>>> httpURLConnection.connect(); >>>>>>>>>>>>> if (httpURLConnection.getResponseCode() == >>>>>>>>>>>>> HttpURLConnection.HTTP_OK) { >>>>>>>>>>>>> %> >>>>>>>>>>>>> <a id="passwordRecoverLink" href="<%=url%>">Forgot >>>>>>>>>>>>> Password </a> >>>>>>>>>>>>> <br/><br/> >>>>>>>>>>>>> <% >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> So every time when user goes to SSO login page need to send 3 >>>>>>>>>>>>> http requests to render 3 hyper links. Also if any of API raises >>>>>>>>>>>>> back-end >>>>>>>>>>>>> exception, bad stack trace will be printed as below. >>>>>>>>>>>>> >>>>>>>>>>>>> WARN {org.apache.cxf.phase.PhaseInterceptorChain} - >>>>>>>>>>>>> Application {http://endpoint.recovery.iden >>>>>>>>>>>>> tity.carbon.wso2.org/}ClaimsApi has thrown exception, >>>>>>>>>>>>> unwinding now >>>>>>>>>>>>> org.apache.cxf.interceptor.Fault >>>>>>>>>>>>> >>>>>>>>>>>>> Is there a better way to handle this situation ? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Gayan >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Gayan Gunawardana >>>>>>>>>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/ >>>>>>>>>>>>> Email: [email protected] >>>>>>>>>>>>> Mobile: +94 (71) 8020933 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> >>>>>>>>>>> Nuwandi Wickramasinghe >>>>>>>>>>> >>>>>>>>>>> Software Engineer >>>>>>>>>>> >>>>>>>>>>> WSO2 Inc. >>>>>>>>>>> >>>>>>>>>>> Web : http://wso2.com >>>>>>>>>>> >>>>>>>>>>> Mobile : 0719214873 <071%20921%204873> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Malithi Edirisinghe* >>>>>>>>>> Associate Technical Lead >>>>>>>>>> WSO2 Inc. >>>>>>>>>> >>>>>>>>>> Mobile : +94 (0) 718176807 >>>>>>>>>> [email protected] >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Isura Dilhara Karunaratne* >>>>>>>>> Associate Technical Lead | WSO2 >>>>>>>>> Email: [email protected] >>>>>>>>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>>>>>>>> Blog : http://isurad.blogspot.com/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Malithi Edirisinghe* >>>>>>>> Associate Technical Lead >>>>>>>> WSO2 Inc. >>>>>>>> >>>>>>>> Mobile : +94 (0) 718176807 >>>>>>>> [email protected] >>>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Isura Dilhara Karunaratne* >>>>>>> Associate Technical Lead | WSO2 >>>>>>> Email: [email protected] >>>>>>> Mob : +94 772 254 810 <077%20225%204810> >>>>>>> Blog : http://isurad.blogspot.com/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Hasintha Indrajee >>>>>> WSO2, Inc. >>>>>> Mobile:+94 771892453 <+94%2077%20189%202453> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Pulasthi Mahawithana* >>>>> Senior Software Engineer >>>>> WSO2 Inc., http://wso2.com/ >>>>> Mobile: +94-71-5179022 <+94%2071%20517%209022> >>>>> Blog: https://medium.com/@pulasthi7/ >>>>> >>>>> <https://wso2.com/signature> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> >>> Best Regards, >>> >>> Nuwandi Wickramasinghe >>> >>> Software Engineer >>> >>> WSO2 Inc. >>> >>> Web : http://wso2.com >>> >>> Mobile : 0719214873 <071%20921%204873> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Hasintha Indrajee >> WSO2, Inc. >> Mobile:+94 771892453 <+94%2077%20189%202453> >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777776950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > > _______________________________________________ > 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
