I'm interested in knowing whether a session is created by pages requested by web crawlers and bots. I am using MySQL as a the session store and would like to prevent requests by web crawlers and bots from creating unnecessary session entries.
Since your server creates sessions, every request to it, would create a session :)
Related
ASP.NET MVC 4.7.2. I am getting some users' information from Azure AD and store that in session so I do not have to call back again until session is live.
But the problem is when the user close the window or signs out, the session also ends, however user can still sign in without authentication process.
So I want to sync save the user information in the same cache or cookie so both expires at the same time. I thought of using the httpContext but read it might create some problem. Currently I am using a session but it is not a good choice. I found some other solution but they are very old.
Thanks
As long as there is no sensitive data cookie seems to be the best choice. You can also use the MemoryCache option but it will be shared by all users.
Hi I'm currently working in this application that consumes some API to retrieve and send all the information, the API manage the database and in my side (Rails app) there is no database.
I was told to use redis to store the sessions so here I am working with redis and no databases, my models don't use ARecord nor AResource. With this in mind I'm working in a logout method but since I don't have any database I'm not sure of what is the approach I should take to handle this because the session is stored in redis and I don't know the keys of the session and also I don't know how to link that session with the user logged I have no idea of how to delete this session.
I'm open to suggestions but it has to be a redis kind of solution, there is any authentification for rails working with redis out there?
Have a look at https://github.com/jodosha/redis-store.
Redis Store provides a full set of stores (Cache, I18n, Session, HTTP Cache) for all the modern Ruby frameworks like: Ruby on Rails, Sinatra, Rack, Rack::Cache and I18n. It natively supports object marshalling, timeouts, single or multiple nodes and namespaces.
I want to to decouple some parts in my rather large app and delegate them to an external node app, mainly for uploads but authentication remains a problem.
On the Rails side I'm using Devise, clients and forms will point to this new subdomain where the node app resides.
The node app is using express and I can connect to the shared database through the mysql module.
The idea is to use heroku for the main app, and delegate uploads to a node app running on a EC2 instance. In order to access the app I want to pass authentication informations, given that this endpoint will used by both API clients and web forms.
Devise has support for authentication tokens passed via URL, but I'm wondering what are your solutions.
Well if your subdomains are just 1-dot apart like www.myapp.example and uploads.myapp.example, you can share both the session cookie and the session info in the DB. I would just code the node app to validate the session cookie on every request the same way devise does and you're done. Is the upload subdomain user facing, as in does it render HTML to the browser or have to display a login form? If so, than the shared session table in the DB is probably not the best idea, but if the node.js is just for uploads and can redirect to www.myapp.example when the session is not valid, all should be well. Just make sure you set the domain field of the cookie to .myapp.example.
Ultimately we want single sign-on for two applications, one is a rails app and one .net.
Is there a way login to a rails application using devise and cookie session store, and have a .net read this cookie to determine what user is logged in? We are open to switching session stores if that would help.
We would like to keep all auth in Rails, but use the cookie session to allow or deny access to .net application.
Yes, you definitely can do this.
If the session is stored solely in cookies then all you need to do is parse the cookies like rails does. Take a look at ActionDispatch::Request::Cookies to get a better feel for how rails uses cookies.
If on the other hand you store the session in Memcache, Redis, Mysql (or any other external store) you can get the session id from the cookie then look it up in the external store. This is probably easier and slightly more DRY.
As long as you have access to the session cookies you should be able to mirror the Rails session manipulation code in your .NET application and "share" session. I encourage you to start by reading deeper into how Rails handles session.
i am writing an asp.net mvc c# site which will not use sessions... What are my options for prividing login functionality without sessions?
System.Web.Security.FormsAuthentication uses cookies:
FormsAuthentication.SetAuthCookie(userName, rememberMe);
No session is used there. Of course, if you want more than a username and isAuthenticated, you'll need some other way to store that state. Your only real alternatives are cookies or the URL, neither one of which are generally acceptable for other reasons.
Session is not evil, especially given your options to host session data on a shared server or on a SQL Server instance.
Session can certainly be abused and your scalability will suffer, but I would not eschew session completely unless there were other overriding concerns.
If you must toss out session entirely, you will have to either recreate state on each call, an expensive proposition generally, or you will have to create your own state storage mechanism which brings us back to standard ASP.NET session storage alternatives.
You basically have 3 options, that I can think of, to authenticate HTTP requests.
1) Cookies only, where you set a cookie on the users machine with the necessary information you need to identify them on their next request
2) Sessions. Session will typically also use cookies (to store session information), but don't have to (see http://msdn.microsoft.com/en-us/library/aa479314.aspx)
3) Stateless authentication. This is really only used for non-browser HTTP clients calling webservices. This includes the client signing the http request with a public/private key combination that the server can then authenticate. An example of a stateless HTTP authentication protocol is OAuth (though OAuth as a spec is really geared towards authorization, but authorization by it's nature requires authentication).
See Web authentication state - Session vs Cookie vs? for additional discussion on Cookies and Sessions.
The common approach is to use cookies. See Securing and ASP.NET MVC Application.