1.0 GA release?

[mmoayyed]

Thought I'd ask if there has been an update on the release?

[serac]

I hadn't planned on a 1.0 release mostly because I don't have too much time to devote to release management. That said, it's in production at two universities, which indicates the current HEAD is production ready. Would the 1.0 moniker make you more comfortable? If so I'll tag it.

[mmoayyed]

I actually would like to be able to use this module as a maven dependency in a pending pull we have on CAS, in order to move the state onto the client. I have tested the changes locally, and things do work perfectly fine, but do need a public dependency for the build.

This should really solve issues with session timeouts and blanking out of the login form, etc

[serac]

Is Maven Central a requirement or simply desirable? Trying to avoid Maven Central publishing if possible, but I anticipate it will be needed.

[mmoayyed]

To be exact, you could certainly publish to a different repository and we could pull from there if that's easier for you. If that is going to be troublesome, I could attempt to simply grab the code from here and find a suitable spot for it in cas (webapp-support perhaps)

[serac]

Publishing here is no problem:

https://github.com/vt-middleware/maven-repo

I would probably move the project under our group space, which makes sense since Cryptacular is a dependency anyway. Let me know if that sounds good to you.

[mmoayyed]

Sure. Do please

[mmoayyed]

Quick ping: had a chance to review and publish?

Just for reference, this is the PR I'd like to resume work on: https://github.com/Jasig/cas/pull/345

[serac]

Sorry, haven't made progress. I wanted to make you aware of a potential complication that I have worked through in our own overlay regarding your CAS patch. The dependency graph is spring-webflow-client-repo-1.0 -> cryptacular-1.0-RC1 -> bouncycastle-1.50. That last one is a problem for CAS due to BC being pulled in by vt-crypt, which is used extensively in the X.509 module. I replaced vt-crypt with cryptacular across the board, which was straightforward if time consuming, but that's a consequence I wanted to mention as you plan your CAS-related work.

Also, a cryptacular 1.0 is arguably a prerequisite for this task. I'll try to knock them both out in the next couple weeks.

[mmoayyed]

Excellent, thanks for the insight and the update. I'll check back with you in a couple of weeks. if there's anything I can do in the meantime to assist, let me know.

[mmoayyed]

Quick ping: any updates on the GA?

[mmoayyed]

bump

[mmoayyed]

bump

[serac]

Apologies for not responding sooner. Here's the status:

1. Still blocking on a 1.0 final for cryptacular. I'm trying to keep open the need to add new features or bug fixes that come out of the Shibboleth IdPv3 development effort since they are making heavy use of that library.
2. I have found additional places where the storage design of CAS is incompatible with the design of this component, namely that anything stored in the flow state is serializable.

While the first issue is simply a matter of timing, I think the second is seriously troubling. I continue bumping into places where way too much data is pulled into the data persisted to various storage backends. https://issues.jasig.org/browse/CASC-231, while a client-side problem, is the most recent in a long line of trouble along these lines.

I feel a little uncomfortable advertising this component as a general solution in light of the storage issues. If there were any one place where we could focus attention, it would be a problem we could solve as a prerequisite for this component. But it's a big problem that requires a big, sweeping solution. I don't see that happening, which creates a "use at your own risk" situation that's likely to incur a support burden. I don't have the resources to support the kinds of errors deployers may run into in production in the public CAS support forum (i.e. mailing lists).

Despite my concerns, I'm still open to releasing this more widely, but I do think we need to work out the support model prior if it's to be used (even optionally) with CAS.

[mmoayyed]

Thanks very much for the update, appreciate it.

So, I have few thoughts on the matter and this is just me at this point thinking out loud; there may or may not be any merit to any of this:

I hear you loud and clear on the support model; and I think it would be substantially unfair for you (or VT for that matter) to handle/respond to questions and/or apply fixes and cut releases. In the interest of a wider release, how about moving this codebase to be under Apereo/Jasig on Github? That would allow more developers to contribute, learn and apply patches, and it would simply be easier to cut releases in due time under org.jasig. CAS developers would surely be among those taking on the responsibility of this integration as well so you wouldnt be burned by the multitudes of questions.

I think that would be a first viable step in getting more integration tests going, specially in the context of CAS. I certainly have not had your experience and have only done brief tests with success but it's evident we might run into a few more serialization issues.

I understand the module's primary job is to move the session-based conversational state over to the client. So anything, in theory, that gets put into that session, might become a point of concern, correct? I suppose the biggest point of failure is session replication?

[serac]

how about moving this codebase to be under Apereo/Jasig on Github?

I'm open to that plan. This would be a new project subject to incubation in the Jasig model. What does that look like with Apereo?

So anything, in theory, that gets put into that session, might become a point of concern, correct?

That's correct. It's a fairly challenging analysis to review every single object that gets put into the flow state for serialization support. There are so many entry points that it's spaghetti at best.

I suppose the biggest point of failure is session replication?

No replication with this model. The client holds the single, authoritative instance of flow state.

[mmoayyed]

Cool.

So I think as far as models go, it would be almost identical to the CAS security filter we have up there now; I imagine everything remains the same from Jasig to Apereo. We should probably contact the infrastructure team and ask, but I doubt there would be an issue.

It's evident that we need a lot of integration tests, and as you pointed out, probably should examine everything that gets put into the flow and figure out what possible side-effects may arise from that decision. I am happy to lend a hand with testing this, and if need be, draw up plans for the set of changes that we might need to make to accomodate for this.

This is a fairly annoying bug with CAS for which this module seems to promise a solution. I have spent countless hours troubleshooting session-timeout issues in multi-node environments and it's always confusing and frustrating. I am hopeful that we can find a solution here.

[serac]

it would be almost identical to the CAS security filter we have up there now

I would love for the only decision point to be where to clone the repository, and in this case it would be under the Jasig organization. If that's all, I'm happy to do that today.

This is a fairly annoying bug with CAS for which this module seems to promise a solution. I have spent countless hours troubleshooting session-timeout issues in multi-node environments and it's always confusing and frustrating. I am hopeful that we can find a solution here.

I can say for certain that this component resolves that problem. We've been running it in production for ~6mo now it works beautifully in that regard. I agree it's promising as a general solution that ships by default, but we'll need to carefully document component interactions with flow state as we discussed above.

[mmoayyed]

Great! Yup, I see no barriers to moving the code under Jasig. I'd create a repo and transfer, change package names, etc and then we can start examining all flow entry points.

[serac]

Here you go: https://github.com/Jasig/spring-webflow-client-repo

[serac]

I believe we can close this issue and start tracking issues on the Jasig repository.

[mmoayyed]

Excellent. Thanks. I am going to try and get sonatype snapshots deployed on the new repo, and then resume testing. probably should post a message to the list and call for other volunteers as well.