You also should consider that separate repos have a more confusing marketing/understanding path; where you’d have to say” version X of blah works with version Y of blah”, as opposed to “version X is released. the end"
again, if this all checks out, I’m +1.
brb
Like that would be the guideline
Honestly, we wouldn't let these other repos run free willy nilly.
Alright.... let's give @TheHokieCoder a day to chime in. Otherwise I think we should go ahead, for starters, with two repos: "dotnet-cas-client-redis" and "dotnet-cas-client-mssql".
@serac We can put the Memcached provider on ice for now, but IIRC someone was asking for it and even sent in a PR with code some time ago... so the gist of the code was already available for us.
I'll circle back to all this tomorrow so we can cement the repos then... or at least give @mmoayyed the go-ahead.
Just a heads up, but I'd like to have a .NET Core compatibility discussion maybe next week some time, but I was trying to loop in @srkirkland and he may be away at the moment.
I added/invited two other devs to the room because they've done .NET related CAS work: Noel (https://github.com/noelbundick/Owin.Security.CAS) and Dave (https://github.com/IUCrimson/AspNet.Security.CAS)
I think I should rename issue 67
What is everyone's opinion if I get rid of the web.config transformations when you install the .NET CAS Client NuGet package? My thoughts are for two reasons: 1) It's going to get complicated when we role in .NET Core support and 2) I need to add the base NuGet package as a reference to each of the distributed proxy/service ticket manager NuGet packages (because I need to implement the interfaces defined in the base package.)
For reason 2, when the base .NET CAS Client gets installed into the add-on package (e.g. Redis proxy/service ticket manager) a web.config file will get generated and added to the csproj, but in reality we don't need that.
So I'm thinking for the next build of the .NET CAS Client I want to remove the web.config transformation permanently. If someone already has them, they won't be removed. If it's a new project you'd have to go read the Wiki/Docs to figure out what needs to be added to the web.config yourself as a developer.
For reason 1, a lot of config is going to happen in a project json file instead of the web.config... so the web.config transformations will be unused.
^ sorry, not project.json. What I meant was the appSettings.json file.
@TheHokieCoder even though the repo is using GitFlow, Git makes you initialize GitFlow on every repo clone :-/ (unlike Hg.) Either commit your code to the develop branch (since it's brand new) or open a feature branch and work on the code there.
@TheHokieCoder or clone the develop branch, do your work and then submit a PR back to the develop branch in the origin repo. Up to you
@mmoayyed can you modify all four .NET CAS Client repos so that they all require the Contributor License Agreement signed on pull requests? (i.e. like how you do on the https://github.com/apereo/cas repo)
@/all since the repos are following the GitFlow/GitVersion branch model, how does everyone feel if I change the default branch (in GitHub) to be the
develop branch? This way when people fork and submit PR's they'll be working off of develop and then basing the PR against that in our repo.
I'm all for that. I wasn't paying attention when I created my pull requests into
master, which is why I went and changed the target branch after the fact. I haven't had a chance to look at the contributions documentation (if you've finished that), but if there isn't already, instructions for new contributors on how to fork/create feature branch/pull request/etc. would be most helpful.
It may be way too late, but FWIW, I am also OK with your idea of removing the web.config transformations. I've never liked how the package management tool in Visual Studio reformats your entire web.config file when a new package has something to add or change. And honestly, once I have set up one project with DotNetCasClient, I just copy that config into new projects since they are always very similar.
@phantomtypist I would like to get the ball rolling on development of .NET Core support in the DotNetCasClient project. Do you want to jump in sometime soon and set up the project to support both .NET Framework and .NET Core? I think that you are much better than I am with your understanding of how mutli-targeting works. But, I also understand if you are too busy to do that right now. If that's the case, would it be OK if I started that work? I have worked enough with some of the "in the wild" implementations of CAS with .NET Core that I feel like I can get something good started.
yeah, i'll set time aside this next week.
@TheHokieCoder ping
my CAS SERVER version is 5.1\
So I see you say you have set up your CAS server and now you also have an ASP.NET web application that you want to install the .NET CAS Client into in order to authenticate the application/user with your new CAS server? Is this correct?
We have some getting started info on the wiki in the github repo: https://github.com/apereo/dotnet-cas-client/wiki
The easiest path for installing the code into your ASP.NET application is to add the dependency/reference via the NuGet package: https://www.nuget.org/packages/DotNetCasClient/
2020-11-18 12:36:18,856 ERROR [org.springframework.boot.web.support.ErrorPageFilter] - <Forwarding to error page from request [/samlValidate] due to exception [null]>
java.lang.NullPointerException: null
2020-11-18 12:36:18,859 ERROR [org.apereo.cas.security.ResponseHeadersEnforcementFilter] - <RegisteredServiceResponseHeadersEnforcementFilter is blocking this request. Examine the cause in this stack trace to understand why.>
javax.servlet.ServletException: RegisteredServiceResponseHeadersEnforcementFilter is blocking this request. Examine the cause in this stack trace to understand why.
I haven't been able to work with the app owners to get more info from there end. Has anyone seen this before?
Hello there,
We are trying to enable FIDO2 WebAuthN support in CAS with both Yubikeys and using the built-in browser support for FIDO2, namely for Safari on Mac OS.
While Yubikey registration and authentication works fine out of the box, when trying to register a FIDO2 device using the native Safari support for FIDO2 (without a Yubikey), we are presented with the following error on the registration step :
"java.lang.IllegalArgumentException: Failed to obtain attestation trust anchors."
Any ideas why this is happening and maybe how we can configure our own attestation trust anchors to include other sources than Yubikeys ?
