Hi,
On 22.06.2010 16:40, Justin Edelson wrote:
> On 6/22/10 9:59 AM, Felix Meschberger wrote:
>
>>> One other thing I considered is if there was a way to simply have a
>>> different service interface which allowed for the content of the form
>>> page to be overridden; as things stand, it is a bit of an abuse of the
>>> Servlet interface, but Sling is all about abusing the Servlet interface :)
>>
>> You mean the static HTML that the Form Servlet returns ?
>>
>> Yes I have been thinking of this, too.... But I couldn't come up with
>> good API to do it -- maybe some Fragment based resource "injection" or
>> some ResourceResolver provided resource ?
>>
> Yeah, the template. You can imagine there being three different
> scenarios for drawing the login form (ignoring the include vs. redirect
> distinction):
> 1) default form
> 2) custom form template processed by default servlet
> 3) totally custom
>
> I suspect #2 would accommodate most use cases (like branding the login
> page). #3 would be necessary if your form needed access to other "stuff"
> to be generated, e.g. localization of the login form.
Yes.
>
> Fragments are a natural solution to #2, but I forget the semantics here
> - if a resource in in both the host and a fragment, which does
> getClass().getResourceAsStream() return? I think it is the host, but I'm
> not sure (spec says that the host is searched first, but the ClassLoader
> docs don't appear to require that the first resource found is the
> resource returned). I guess we could always do getResources() and the
> reverse the enumeration (which is probably very ugly code).
Yes. But we can solve this issue by defining the path for the fragment
to provide and the default (fallback) path to be different. Then the
servlet would do:
URL url = bundle.getEntry(pathFromFragme);
if (url == null) {
url = bundle.getEntry(defaultPath);
}
>
> I *think* I solve my search URL problem by implementing a custom
> template and the include logic. If this works, I'll document how to do
> it on the wiki.
Cool.
Regards
Felix
>
> Once you go down the path of using something from the ResourceResolver,
> I think you might as well use a Servlet.
>
> Justin
>
>>
>>>>
>>>> On a related issue: we might want to provide an
>>>> AbstractAuthenticationHandler which provides common functionality
>>>> currently duplicated in the Form- and OpenIDAuthenticationHandlers.
>>> This seems like a good idea to me.
>>
>> Ok, I'l try to come up with something; probably to be placed into the
>> Commons Auth bundle (in the spi package)
>>
>> Regards
>> Felix
>>
>>>
>>> Justin
>>>
>>>>
>>>> WDYT ?
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>
>>>>> if (loginFormServlet != null) {
>>>>> try {
>>>>> loginFormServlet.service(request, response);
>>>>> return true;
>>>>> } catch (ServletException e) {
>>>>> log.error("Failed to include the form: " + loginForm, e);
>>>>> }
>>>>> }
>>>>>
>>>>> Redirects have two problems:
>>>>> 1) They require an additional network round trip
>>>>> 2) They lose state
>>>>>
>>>>> #2 is the problem I'm facing in the near term - as things currently
>>>>> stand, the formauth bundle will not pass through the query and search
>>>>> portions of the request path. As a result, the original URL (say, a
>>>>> bookmark) cannot be fully reconstructed. This is a solvable problem for
>>>>> the query string, but the only way to get the search portion of the URL
>>>>> is on the client side, which isn't possible without doing an include of
>>>>> the login servlet form.
>>>>
>>>>>
>>>>> Justin
>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>> On 22.06.2010 04:05, Justin Edelson (JIRA) wrote:
>>>>>>> have the form authentication handler include the login form as a
>>>>>>> resource rather than doing a redirect
>>>>>>> ------------------------------------------------------------------------------------------------------
>>>>>>>
>>>>>>> Key: SLING-1564
>>>>>>> URL: https://issues.apache.org/jira/browse/SLING-1564
>>>>>>> Project: Sling
>>>>>>> Issue Type: Improvement
>>>>>>> Components: Extensions
>>>>>>> Reporter: Justin Edelson
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
