Once my webpage is deployed in IIS it seems that i am unable to properly switch tenants until i log into the default/host first. I don't want to require my users to have to do this before being allowed to switch to the tenant. It seems like the view is not properly being updated but i'm not sure why. I am using the ASP boilerplate template as a base and have not changed any of the login code/functionality at all.
So i tracked down the issue. For some reason when it goes to set the document.cookie value that includes the path and expire along with the tenant ID for whatever reason the browser is not updating the document.cookie with the according values. The javascript itself is not failing.
The fix is to just set the tenant portion of the cookie by itself and it works. Maybe someone can explain this behavior, but i tested the string and it will update the cookie just fine if i have logged into a tenant or host first.
Just seems once the session times out or is marked as bad this issue comes up.
Related
I've developing an update to an existing Laravel System (currently running Laravel 6 and PHP7.4), that runs on both EC2 and Laravel Vapor Setups, and have run into some very strange issues that only present themselves on Vapor Setups. These issues relate to Cookie Generation Failing and POST Routes being ignored when handling Routes.
Issue #1: Cookies No Longer Being Set
The first issue presents itself immediately upon loading the system up for the first time, no cookies are being saved, even though our .env is configured to do so:
SESSION_DRIVER=cookie
Without Cookies being generated, forms can't be processed and users cannot be marked as authenticated.
The system itself has had no changes made to it in areas that would touch core logic around Cookies, but none are now being generated. If we revert the codebase to the previous release without these changes, the system runs perfectly on the Laravel Vapor Setup, but runs without issue using both version of the code on the EC2 Setup.
Potentially Related: Redirecting users seems to be being done with JavaScript on the problematic Vapor Setup, whilst EC2 and Local Development Environments are managing to do so using headers. This indicates there's an issue somewhere in the code that's being used, but the areas that manage that code, as mentioned a few times, haven't been touched during development.
Issue #2: POST Routes Being Ignored
This might be a run on from the first issue above.
POST Routes are being completely ignored from our web.php file. I've tried submitting forms, I've tried using Insomnia to make requests to them, and have even tried setting up a route that would catch requests to any route that was using the POST method, and in each case they were being completely ignored by the system.
Submitting our login forms leads to a strange error being output:
Call to a member function can() on null (View: /var/task/resources/views/core/main/parts/headermenu.blade.php) (View: /var/task/resources/views/core/main/parts/headermenu.blade.php) (View: /var/task/resources/views/core/main/parts/headermenu.blade.php) (View: /var/task/resources/views/core/main/parts/headermenu.blade.php)
This error is strange because it should only be displayed after a user is authenticated, but submitting any details to the system gets this output, even blank details. I'm not sure how the user ends up on an authenticated page, as the POST route that handled authentication is being ignored, so no authentication logic is ever being run. I can, at least, confirm that the system is able to connect to the database to run verification logic, but the route that does so is never accessed because of this issue.
Honestly, I'm coming up blank on solutions to both of these issues, but they're blocking progress with this feature. Any and all guidance on where to look, or how to resolve the above would be most greatly appreciated.
I am working on Laravel 4 application and using Sentry for authentication. I need to add Keep Me Logged In functionality into my application. I have googled around and found that passing second variable to Sentry::login($user, $remember) sets up a cookie. I have done that and can verify that it is working from the browser (Chrome). But somehow whenever I try Sentry::check() after a day it returns null for cookies. Even when the cookie is present in the browser. Can anyone point out what am I doing wrong? Same happens when I attach my custom cookie to the response.
This scenario happens on my production server. Whereas it works fine on my local server.
PS: Lifetime of the cookie is set to forever (5 Years)
After working around for sometime on the issue I was finally able to resolve the issue by creating and attaching custom cookie to the response after login. And then wrote a middleware to check for that cookie. If present then login user and continue.
Our Laravel 5.1 application has been using the "native" session driver setting (configured in the .env file). With it set this way, we were able to use the laravel url.intended behavior to redirect the user to the url they were attempting to access prior to being authenticated.
We had to change it to "cookie" because every time we use Amazon's Opsworks system to deploy a new build, users were logged out because their server-side session files were no longer available. Once we changed it to cookie, the users remain logged in even when we deploy a hotfix or new build.
However, with it set to cookie, the url.intended does not work at all. I tried hacking together some solution by adding a custom url intended node, but it just won't work. It seems like when the user attempts to access a url prior to being logged in, it sets the session info, but then the application redirects the user to the login page where it's getting nulled out.
I'm using Debugbar to look at the session vars and I'm going crazy. I'm already bald so I have no more hair to pull out.
Does anyone have any ideas?
We ended up setting up a Dynamo database at first and then transitioned to Redis on a common server. We have a load balancer and don't want sessions getting lost or corrupted by switching servers so all cache is now being stored in that common location.
I'm just installed a fresh L5 app. I'm attempting to use database driven sessions however a new session appears to be created on each page load.
Has anyone come across this issue and managed to resolve?
"_token" value is new on each refresh.
I'm happy that the cookies have been configured correctly.
Not sure where to look next.
Any suggestions would be a huge help.
Thanks in advance
Have you ensured your session domain is set correctly? Your session domain should be the domain alone, for example domain.com, no URIs or protocols (http://), etc.
You may also want to check that SESSION_HTTPS is set to false, unless you're accessing your site over https.
If either are not set correctly sessions will not be correctly stored by the browser, so each request results in a new session.
The _token key will always be a new value for each request, this is part of the CSRF security feature.
I have two MVC3 sites, both hosted on the same server that I've configured to use the same authentication cookies.
The first site is an intranet site using Windows authentication. This site has one simple Action that checks to see if the user was authenticated, if the user has been, it creates a FormsAuthentication cookie that it adds to the response. This cookie is created for a generic user that I determine from the User's AD groups. The response then redirects the user to a second site that uses Forms Authentication.
When I run this on my local machine, everything works as described above. When I deploy this to our local web server, it doesn't. I've tested to see if the user's group is correctly determined and that it creates a valid user for the cookie, and I have verified that this is correct on the web server.
Here is how I'm doing all of the above:
First, I made both sites use the same same Machine Key for encryption and decryption.
When I create the cookie in Site1, I ensure that it has the same name and Domain as the cookies created on Site2.
var cookie = FormsAuthentication.GetAuthCookie(userName, false);
cookie.Domain = FormsAuthentication.CookieDomain; //This is the Domain of my 2nd site as they are different
HttpContext.Response.Cookies.Add(cookie); //Add my cookie to the response
HttpContext.Response.RedirectPermanent(urlForSite2);
Again, when I run this on my local machine it works without a problem. But when deployed, it's either not passing the cookie in the request, or the response is ignoring it, but I'm not sure how to verify either of these cases.
Feel free to ask any question regarding more details as to how I'm doing this if it will help in getting an answer I need.
Cross domain cookies are not allowed. If you have two separate domains; one cannot access the others cookies. Two separate virtual directories/applications will work when using the same machine key. http://blogs.technet.com/b/sandy9182/archive/2007/05/07/sharing-forms-cookie-between-asp-net-web-application.aspx
If you want to share login cookies between sub-domains you need to edit the Domain property of the login cookie to the 2nd level domain "abc.com" so that "www.abc.com" and "ww2.abc.com" will have access to the cookie. http://forums.asp.net/t/1533660.aspx
String usrName = User.Identity.Name.ToString();
HttpCookie authCookie = Security.FormsAuthentication.GetAuthCookie(usrName, false);
authCookie.Domain = "abc.com";
Response.AppendCookie(authCookie);
Actually, it is possible, but isn't as simple as the domain/sub-domain cookie sharing.
http://www.codeproject.com/KB/aspnet/CrossDomainSSOModel.aspx
While the example given in this article didn't apply directly to what I was doing, I could use some of the ideas expressed there to get what I needed working. It ended up being my configuration settings in site2 web.config.
My URLs are as follows
Site1 = http://site.stage
Site2 = http://site.stage.MyCompanyName.com
Site 1 requires a host entry addressing it to a specific IP address of the hosting machine. It's also an entry in my IE Security settings - Local Intranet Sites.
I should note that these applications are both virtual directories running under the same default website.
I thought I had solved my problem but setting the Domain in the config file to and empty string, but this didn't work. I'm not sure what can be done now. This still works when I run it on my local machine, but not when I run it on my server. The only difference is the urls.
My dev machine is using the urls
Site 1: http://localhost/CompanyName.TVAP.IntranetSite
Site 2: http://localhost/TVAPDev/
I hope this adds some clarification. This Answer should really be posted as an edit to my question, but when I originally posted it, I thought I had it working.
UPDATE: I think my answer is in my URLs above. My dev machine URLS both are using the same domain name, which in this case is localhost. I think if I alter my deployed websites to use the same domain, I will be OK. I'll post an update when I get it worked out.