I was playing around with storing session ids for anonymous users in django models using django.contrib.sessions.models and tested all browsers on my machine creating different keys sometimes based on the real and incognito sessions.
I followed it up by deleting my database and creating a new one as part of my tests and development emptying out all tables.
I am noticing now that when I revisit the site from the same computer/browser, django does NOT create and store a new session id even though the table is empty which means that the server is storing the information that I previously visited the site as an anon user somewhere other than the django_sessions table.
I tested clearing out my cookies and history but that did not help. Does anyone know where that information is stored, why, and how can I reset it? This is an issue mainly because I am using the session id as foreignkey and if i do end up deleting the database after deployment for any reason, i dont want the program to not work properly.
Using python 3.8 and django 3.0.2
Thanks.
Related
I'm in a brain-breaking problem here. I've created a nice Magento 2.1.7 installation with two websites (two stores, two domains) and somehow after a while we are unable to login the backend of Magento.
Invalid Form Key. Please refresh the page.
Now, after trying a few options, still no success. Checked core_config_data, edit max_input_vars, nothing works. The strange thing is, on the front it's still possible to checkout and do your shopping.
Anyway, I'm stumped here. Why is this happening, and how can this be fixed. Any help is welcome.
I often get this error, clearing the cookies for that site, then opening the admin panel in a new tab will resolve this.
You can recreate this error message if you double click the login button after filling out your login information.
Here are a few other reasons you may experience this issue
The form key inputs are outside of the form, you should check the html on the admin panel to check these inputs and exists and have correct values
Make sure the link you use to get to the admin page does not already have a form key in the url
Does this issue generate anything in var/log/system.log ?
Eventually, nothing helped, but what did the trick was creating a new install, setup this new install with all necessary modules (fortunately there were only four), configure the fresh installment like the old one (long live GitHub) and compare your fresh installation to the old one in the database table core_config_data. Basically reproduce your entire setup without any products in it, but just create your stores and categories.
If you spot any differences between the new installment and the old one in the core_config_data, edit them in the old one to be the same as your new one.
Next, edit your env.php with the database credentials to the old database which you've compared and edited.
And the last step, recompile, flush/clean cache and reindex.
Oh, and word of advice, if you're going to use https for your store, setup magento on https. I think something went very wrong when we've changed the base url's from insecure to secure.
I'm having a weird issue with Backand. I created an app, a couple of tables, inserted data, and created a query using their web frontend. Integrated Backand in my Ionic2 app, worked great. A few hours later I added a couple of queries, and got the error message that the object doesn't exist when using the query. I changed the query I used successfully earlier, and got the same result as before the change - so the changes to my queries where not synced to the server (I'd assume). I added a field to a table I did this.backand.object.getList('items') before, but the field was missing. Strangely the data I am adding to the tables, or changing is correctly shown in both my app, and the web frontend.
In summary - data is the same in web frontend and my app, any changes to data model, or queries are shown in web frontend but not in the app.
Anyone has seen that before?
Never mind, 8 hours later everything is in sync. My query can be used in the app, changes to the data model are also seen by the app (through the API).
I set up a simple django site using django-allauth.
I created some oauth providers in the database.
Everything is fine and working on my laptop now.
I would like to store the created database tables somehow.
Use case: I want to set up a new development environments on a different PC painlessly.
How to store the initial data of django_allauth, so that after checking out the app from git the command manage.py migrate is all I need to have the relevant database tables filled?
Django_allauth already save those data to the database, you will find them in a table *_SocialApp, here is the model code from django_auth source
I've set up a local Sitecore environment with all sql and mongodb db's working.
Except i do not get any data in the experience profile (contacts)
I see that tracking_contact db is empty in mongo and also the analytics index folder is empty.
Other functionalities like experience analytics work fine.
Are there any extra configurations necessary?
The Experience Profile runs on the Analytics index. If there is no index, there will be no data shown.
Try to rebuild the index if it's not there.
There is an admin tool for rebuilding the reporting db & analytics index: /sitecore/admin/RebuildReportingDB.aspx
When you run the tool you must setup a secondary reporting db first.
Just attach another empty analtyics database to your local SQL and name it something like analytics_secondary and configure its connectionstring.
Then rebuild the reporting db and after that data should appear in your Experience Profile.
The index should be constantly refreshed by the aggregation framework (i.e. you should not need to rebuild) so if that is not happening, something is wrong in your configuration.
When working with xDB you'll need to identify a user to get it to appear in the experience profile section otherwise they will be anonymous.
Try using this code here to create a contact:
https://github.com/ianjohngraham/CoreBlimey.Utils/tree/master/CoreBlimey.Utils/xDB%20Contact%20Creator
And then call the end session by using the button.
If everything is setup correctly then the contact you created will appear in MongoDB and in Experience Profile.
If you are still not getting any data then you could try these things:
Ensure you have the <sc:VisitorIdentification runat="server" /> control for asp web forms layout
the #Html.Sitecore().VisitorIdentification() control for MVC layout
Make sure you disable robot detection by changing this setting <setting name="Analytics.AutoDetectBots" />
Charley,
I also had the similar problem in past, so what I found was, it was not working in my local, but when i put it stage server it shows data to me. So same may apply to you also.
Also without "#Html.Sitecore().VisitorIdentification()" in your Layout tracking is not possible.
Hope this will help you.
cheers!!
I have a weird bug with django sessions in my app: some times (about 10 times for ~20000 per day) session information for user is erased. I traced it via log files: at page A there is information for user's session, after it he submits the form and at the next page his session is empty. I tried two types of storage: memcached+db and db only and this problem is for both of them. I tried to reproduce these scenarios, but all works as expected, as I said, it happens very rare. I also checked that this problem exists for different users, and for them is doesn't reproduce each time. I don't have any ideas how to catch the root cause and I don't know what else post here as a description. If someone has any ideas, please let me know. If it is important, I'm running my app with django 1.2 + FastCGI.
Thanks!
UPD: I checked and see that session key from uses is not changed during two sequential requests, at first request there is an actual session state, and at second session variables are relaced with empty.
As a way to debug this problem, I would subclass the standard Django session middleware (or whatever you're currently using):
django.contrib.sessions.middleware.SessionMiddleware
and wrap process_request and (probably more importantly) process_response in some extra logging. Then install your subclassed session middleware in the MIDDLEWARE_CLASSES, rather than the stock Django one.
You could also validate that session.save() has actually committed its changes by attempting to read it back. It could be that the problem lies in session-state serialisation, and it's failing on a particular key or value that you're attempting to store.
None of this will fix your problem, but it might help you to establish what's going on.
As #Steve Mayne mentioned, it would be good to do some logging on the sessions middleware and sessions model save method. That's something I'd start with.
In addition I'd like to say that this could be a database related issue, especially if you're using MySQL database backend for sessions. You can check the log for database locks and other concurrency issues. I had to deal with similar issues before and the solution is clear: optimization and additional performance.
If you have some specific application middleware, you can check for functionality that interferes with Django sessions. Such parallel operations can cause problems, if not implemented properly.
Another thing I would do is to upgrade to the latest stable release of Django and migrate to a mod_wsgi setup.