getPrincipals() typing

[Klingenstein, Nate]

> > Yeah, that was what I was after.  There are no semantics or constraints
> anywhere.
> 
> There are semantics and constraints in many places, just not in those classes
> or interfaces. A UsernamePrincipal is exactly what it says it is. A Principal is
> not always a UsernamePrincipal, but a UsernamePrincipal is one type of
> Principal.

None anywhere relatively speaking.  There are some, but there aren't.  I now understand the rough outline of Principals and Subjects in Java, and... wow.

I'm all for indirection and recycling, but I don't get why in this instance.  Why reuse Principal if you can't make any assumptions about it at all and it forces you to use the janky data structure?

> You should be, that was an incredibly hard feat of engineering that I didn't
> even think would work until I tried it and it did.

I need to be able to explain this to others.  That's pretty much the same excuse I have for all of this.

> The flow executing is the flow definition assigned to the location you start
> the browser at.

That's what I suspected.  That would mean they're relative not just to the current flow, but the invocation point.

The entire URL is apparently used to do dispatch.  authn/Password?s1e2 is entirely different from authn/Wrapper?s1e3, but they could be landing at the same point.

> You should have no need to worry about any of the webflow execution
> machinery, that's all automatic. The only thing you have to do is use the
> flowExecutionUrl inside any forms or redirects and the rest is all done for
> you.

I appreciate that all of this is done by Webflow, and that's where I will end up after this message finishes routing.  I'm not trying to change how it works, but I do want to understand it all.

> >    There basically is no entrance nor exit.  There's basically no state
> anywhere.
> 
> Other than that being incorrect, I don't know what to tell you. There's state
> all over the place like with any complex application, and the places where
> subflows can get called is entirely proscribed.

It's proscribed if you have it all in your head.  I can assure you that, if you don't know the implementation well, it feels like there is no state.

I now understand why you would need a new developer to spend months reading the code to come up to speed.  You need to have an incredible amount of stuff in working memory, or you need to trace everything down to the letter.
 
> Specifying classes is what the T() syntax does in Spring. Without that, you just
> have an error. I'm just saying that not specifying the Principal type at all is
> pretty much always incorrect. It's fine if you're trying to iterate over every
> Principal, but randomly grabbing one will not give you anything predictable.

Okay, then I just had an error.  I'm not comfortable with any of the assumptions here from the iterator on, so this will get thought through.