State mismatch in application without database #129
-
|
I'm getting a state mismatch error when attempting to sign in: I can get to the sign in page and go through the signing in process, but I then get the error and am redirected back to # Tells the Flask-session extension to store sessions in the filesystem
SESSION_TYPE = "filesystem"
# Using the file system will not work in most production systems,
# it's better to use a database-backed session store instead.The thing is that I have a very simple application with which I want to allow a user to sign in and, after they are, run a process for which I don't need a database. Is there a recommended way to implement this if no database is used? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
It is unclear whether you changed that
The mentioning of database in
Could it be possible that you also modified this sample in some other way? Also, what is your configuration (you do not need to tell us your app's client_secret)? What is the output of |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the quick and helpful reply @rayluo! My import os
AUTHORITY = os.getenv("AUTHORITY")
CLIENT_ID = os.getenv("CLIENT_ID")
CLIENT_SECRET = os.getenv("CLIENT_SECRET")
REDIRECT_PATH = "/auth/redirect"
SCOPE = ["User.Read"]
SESSION_TYPE = "filesystem"My environment variables are these (I changed some values to zeros to not share them publicly): [
{
"name": "AUTHORITY",
"value": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000",
"slotSetting": false
},
{
"name": "CLIENT_ID",
"value": "00000000-0000-0000-0000-000000000000",
"slotSetting": false
},
{
"name": "CLIENT_SECRET",
"value": "0000000000000000000000000000000000000000",
"slotSetting": false
},
{
"name": "SCM_DO_BUILD_DURING_DEPLOYMENT",
"value": "1",
"slotSetting": false
}
]You mentioned What I have noticed is that after I go through the sign in process I'm redirected to Something I'm confused about though. You write:
But the
Saying it will not work on most production systems reads to me more like a requirement than a suggestion, but just to confirm: using the file system for sessions should work when deployed as an azure web app? |
Beta Was this translation helpful? Give feedback.
-
File system does not scale well, database does, that's why it is a suggestion to use database in production. And if you happen to build a popular website that has busy workload, file system may not keep up with your workload, your website may feel unresponsive. At that point, using database would become a requirement - required by your workload. But until then, file system is functionally adequate. We tested this sample app with its default file-system setting and it should work. At the least, the file-system VS database shall not result in different behavior if you are deploying to only one server. Which brings me to my next question. How many web servers are you currently using in your setup? I ask this because,
the shape of your configuration file is different than an
By the way, you think my previous response within 8 hours was quick? How about this new response with 48 minutes, in an early Saturday morning in my timezone? :-) That said, now I need to catch some sleep. Yawn. |
Beta Was this translation helpful? Give feedback.
-
This was an excellent question and observation, as this is exactly what was happening. I reduced my service plan to one instance and then had no issues. Unfortunately I cannot do this on production, so I will add a database for unified session storage.
8 hours is quick, 48 minutes is too quick, especially for a weekend! 😅 No but seriously, thank you very much for the quick but most of all useful responses! I really appreciated it! UPDATE: Also read this follow-up conversation. |
Beta Was this translation helpful? Give feedback.
-
|
Small update: in the end I will keep using the filesystem. This seems to work well in combination with using the affinity cookie to ensure users are sent to the same instance for subsequent requests.
|
Beta Was this translation helpful? Give feedback.
-
Thanks for sharing! Yep, affinity cookie is also another excellent solution. I'll add this learning into this sample's configuration file soon. P.S.: This response came within 37 minutes. :-) |
Beta Was this translation helpful? Give feedback.
This was an excellent question and observation, as this is exactly what was happening. I reduced my service plan to one instance and then had no issues. Unfortunately I cannot do this on production, so I will add a database for unified session storage.