custom flow problems

[Jim Fox]

I see this note about flow inheritance.

    Paths to external resources in the parent flow should be absolute.
    Relative paths will break when the two flows are merged unless the parent
    and child flow are in the same directory. Once merged, all relative paths
    in the parent flow will become relative to the child flow.

    http://docs.spring.io/autorepo/docs/webflow/2.3.x/reference/html/flow-inheritance.html

might be the cause.

Jim




On Fri, 16 Jan 2015, Jim Fox wrote:

> Date: Fri, 16 Jan 2015 14:35:18
> From: Jim Fox <fox at washington.edu>
> To: Shib Dev <dev at shibboleth.net>
> Reply-To: Shib Dev <dev at shibboleth.net>
> Subject: RE: custom flow problems
> 
>
>
> I'll investigate some more, but an initial look shows:
>
> When it works, remoteuserplus in system/flows/authn, I see this flow:
>
>   Calling subflow 'authn' with input map['calledAsSubflow' -> true]
>   Entering state 'AuthenticationSetup' of flow 'authn'
>   ...
>
> so it is 'doing' the authn-flow.
>
> When it does not work, remoteuserplus in flows/authn, I see this flow:
>
>   Calling subflow 'authn' with input map['calledAsSubflow' -> true]
>   Entering state 'RemoteUserActionChooser' of flow 'authn'
>   ...
>
> It is going directly the the remoteuserplus flow, skipping authn-flow entirely.
> Thus PopulateAuthenticationContext never gets called.
>
>
> Earlier on I see this line in the working version:
>
>   Loading XML bean definitions from file [/data/local/idp-3.0.0/system/flows/authn/authn-beans.xml]
>
>
> which I never see in the non-working version.
>
> So, for some reason the auth-flow now its bean definitions ever get loaded
> when I run a flow out of the local flows directory.
>
> Jim
>
>
>
> On Fri, 16 Jan 2015, Cantor, Scott wrote:
>
>> Date: Fri, 16 Jan 2015 13:01:52
>> From: "Cantor, Scott" <cantor.2 at osu.edu>
>> To: Shib Dev <dev at shibboleth.net>
>> Reply-To: Shib Dev <dev at shibboleth.net>
>> Subject: RE: custom flow problems
>>
>>> The filenames have to be very specific to create a user flow and have it
>>> located. But I don't understand how you could ever get far enough to reach
>>> the servlet without it finding the flow, and it can't run the flow without
>>> setting the attemptedFlow property, unless there's a bug.
>>>
>>> I'd have to try to reproduce it or see a log trace.
>>
>> FWIW, the place setAttemptedFlow is called is logged on DEBUG here in the SelectAuthenticationFlow action:
>>
>>        log.debug("{} Selecting inactive authentication flow {}", getLogPrefix(), descriptor.getId());
>>
>> So you should have that in the log. For your servlet to be running, your flow had to have been called, and that log line has to have run for that to happen.
>>
>> -- Scott
>>
>> --
>> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
>>
> -- 
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
>