Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jason Kanaris
    @phantomtypist
    @mmoayyed with regards to the maintenance.... I think it's better to keep these ones separate and being on their own release cycles.
    Misagh Moayyed
    @mmoayyed
    If not, then probably should take out “store"
    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"
    Jason Kanaris
    @phantomtypist
    @mmoayyed .... yeah, I was thinking that too. I'm 97.5% sure the project is only going to use this for service/proxy ticket storage.
    Misagh Moayyed
    @mmoayyed
    you also have a higher chance of breaking stuff, until contrib modules catch on with the latest “breaking API” changes.
    again, if this all checks out, I’m +1.
    brb
    Jason Kanaris
    @phantomtypist
    Marketing/understanding => I was planning on aligning them with major versions. I.e. .NET CAS Client Redis package v2.x is only compatible with .NET CAS Client core package v2.x
    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.
    Marvin S. Addison
    @serac
    Ah, ok. Yeah, we should accept contributions. Carry on :)
    Jason Kanaris
    @phantomtypist
    :D
    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.
    Jason Kanaris
    @phantomtypist
    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)
    Scott Kirkland
    @srkirkland
    Hi @phantomtypist -- yea .NET Core compatibility would be awesome. I'm using the AspNet.Security.CAS package you mentioned above and it works for .net core so that might be a good place to look at
    Jason Kanaris
    @phantomtypist
    It's not really just .NET Core support though. At a higher level it's about getting an OWIN provider in-place that covers both .NET 4.5 and .NET Core.
    I think I should rename issue 67
    Jason Kanaris
    @phantomtypist
    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.
    Jason Kanaris
    @phantomtypist
    I think the documentation on configure the web.config is pretty good
    Jason Kanaris
    @phantomtypist
    @TheHokieCoder I scaffolded the the MSSQL proxy/service ticket manager nuget package project.
    @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
    Jason Kanaris
    @phantomtypist
    @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)
    Jason Kanaris
    @phantomtypist
    @/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.
    TheHokieCoder
    @TheHokieCoder
    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.
    TheHokieCoder
    @TheHokieCoder
    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.
    TheHokieCoder
    @TheHokieCoder
    @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.
    Jason Kanaris
    @phantomtypist
    heyyyyyyyyyyy
    yeah, i'll set time aside this next week.
    @TheHokieCoder ping
    AnmolBudhewar
    @AnmolBudhewar
    my cas server is complete now I want dot net client for cas please help me for installing the dot net CAS client with details information and Also i need to know how to deploy it
    my CAS SERVER version is 5.1\
    Jason Kanaris
    @phantomtypist
    @AnmolBudhewar sorry, I didn't seem to have gotten a notification that you commented.
    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/
    dksteiner
    @dksteiner
    Hi, we have a client that's using the DotNetCasClient and I'm upgrading my Test tier from cas v3.6 to v5.3. Their samlValidate call shows an error:
    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?
    lshc
    @lshc666

    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 ?

    Jason La
    @jasonla
    Hi. Is there an update on the ASP.NET Core/6 client lib? Last I saw in the official repo, it hasn't been worked on for 2 years