Activities of "aptys"

We followed the instructions as recommended, first from the PR (where we provided feedback) and finally at the blog post HTTP-Only Cookies in ASP.NET Zero Angular UI | ASP.NET Zero (aspnetzero.com). We need to support CORS and have managed to get the cookies to download when the Angular app is a different domain (we can see them in the browser for the application), but the session in the Angular app is not getting the user information. We think that the issue is in the ABP framework where the session is constructed, but we don’t know. It seems to work when we copy the app to wwwroot as recommended in the blog post, but we don’t run that way in production. We’re on v11.4 and have adapted the recommended changes for that version.

Will implementing this be more successful on v13.x because it’s based on a later version of ABP? (The change history does not indicate that it will be, but we didn’t look at all the PRs.) If not, is there a way to get assistance to look at our specific code for this issue? If so, what’s involved with that?

We use version 11.4 of the ASP.NET Core + Angular version of ASP.NET Zero, and I have a question about the HttpOnly attribute for the authentication cookies. The auth tokens are created by the Angular app, and because they are created by the client they cannot have the HttpOnly attribute when they are created. The Angular app appears to access the contents of the auth Abp.AuthToken and enc_auth_token after they are created, which means that they can never be marked HttpOnly.

The only information that I can find in the ASP.NET Zero documentation related to the HttpOnly attribute for cookies is in a fairly old report, https://docs.aspnetzero.com/en/common/latest/Security-Report-Core, but the notes about HttpOnly in that report do not seem to address the auth cookies.

Here’s my question: Is my description of why the authorization cookies cannot have the HttpOnly attribute accurate? If not, is there other ASP.NET Zero documentation that describes this?

Unfortunately, at the moment it is built on .NET Framework and WebForms, so we can't use IdentityServer4. IdentityServer3 would have been a possibility, but it's gone out of support and therefore isn't an option.

We have an ASP.NET Zero application, and then a separate web application that already performs user authentication. We would like for users logged in our external application to be able to click on a link that then takes them to the ASP.NET Zero application as that same user.

• Is it possible to create an authorization token from that application, then to redirect the user to the ASP.NET Zero web site and have the user use that token?
• Or is it possible for us to create our own IExternalAuthProviderApi implementation where we can do something like this?
• Some other option?

Note: I investigated using OpenID and WSFederation in our external application, but I don't believe they would work because our external application itself can be configured to have it's identity provided by various SSO systems.

I believe you are right about the configure being called for each instance of the service.

It appears as though the issue may have been a combination of several things:

• Log4net logging was missing because I disabled the rolling log file appender, since we wouldn't have access to write to a log file in the Lambda environement. I've since changed this to a ConsoleAppender, since the console output gets automatically ingested into CloudWatch logs.
• The database could not be accessed do to security restrictions on the Lambda environment
• Cold startup of the application takes a pretty long time, maybe (1-3 minutes). I have not yet diagnosed what the cause of this is. Once it's warm, requests are processed very quickly.

Once I fixed the database security issue, increased the timeout for the Lambda's from the default 30 seconds, upped the memory limit for the Lambda from 256 to 512, and fixed the log4net configuration, I was able to get the system to start returning some requests.

I will be continuing to work with this configuration and will write another update once I know more.

We're trying to get ASP.NET Zero to run on AWS Lambda (the Amazon version of Azure Functions).

Each call to the service appears to take 2-4 minutes to execute. I've traced it down to it spending almost all of that time in the app.UseAbp() function within the Startup.Configure class.

Question: Do you have any idea what it could be spending it's time on here, or is there any way to tell what part of UseAbp() is taking all this time?

Additional Details:

We've been able to successfully build and deploy the .NET Core 2.1 version (using ASP.NET Zero v6.3.1.) to AWS Lambda, after having followed the same steps outlined at https://forum.aspnetboilerplate.com/viewtopic.php?p=29608.

We've been able to see where it's taking it's time by putting some additional diagnostic logging in various places in the Startup class.