I am using MVC5, EF6, AspNet Identity 2.0.
The views need to periodically check server for new notificiations, this is done by javascript/jquery get periodically reading a server side GET action.
Unfortunatelly, even the action having [AllowAnonymous], I found that action executes "OnValidateIdentity", I mean that sometimes the cookie expiration timeout is refreshed.
If the user just keep the page open, the logon will never expire... This is bad.
I read that javascript/jquery can't send a cookieless request. Seems that MVC5 server-side it is impossible to ignore the cookie in determined action.
I'm stuck... Any suggestions? Thanks in advance.
I found that best way is to use SignalR to notify the open pages about new notifications.
Javascript pool reading a server side GET action is not so smart, as it consumes more resources.
Related
I am working on an asp.net C# webforms project. I want to redirect to login.aspx page when the session expires. I have the javascript based solutions available on the internet which work fine. However I would like it to work off of global.asax page so that the code will be in one place. I tried to redirect from the Session_End event on the Global.asax but didn't work as no Response and Request object available to this event. There were some references to use Application_AcquireRequestState event as in Redirecting to another page on Session_end event but it didn't work either. Any help is greatly appreciated.
Thanks
It's been a while since I've lived in the .NET world, but as far as I recall, Session_End fires on the server without any request triggering it. In other words, when a session expires, Session_End will fire. You won't have a Request at that point in time.
Also, if you ever need to move to external sessions, Session_End won't fire:
https://blogs.msdn.microsoft.com/amb/2011/06/03/session_onend-or-session_end-events-in-global-asax-wont-fire-if-you-store-asp-net-sessions-out-of-proc-in-state-server-or-sql-server/
So, you may not want to rely on Session_End in the first place.
Since you don't have a Request, you can't do a redirect from the server. You have to do it in JavaScript. But if you really need the server to "push" the redirect to any connected clients, you could use WebSockets to accomplish this. (I think that would be a bad idea, though.)
I would like to know if the following is possible and if it is please guide me in the right path.
My site is x.com and when a user submits a form on my site an API call is made to y.com which returns a JS hash (yeah very outdated, I know).
You can see the call to y.com being made in FireBug with returned params. Problem is that Adblocker Plus is intercepting this content and blocking it from view. (Not good (displaying a message about ad blocker is not a solution (In this case the user is actually expecting the ad)))
Is it possible to have my server make the request to y.com server (without the user's client being aware) get the response on my server side, and then finally generate the page and with the response content in the body, and lastly render to client?
This is entirely possible. You could define an endpoint on your local rails app (x.com) and submit the form to that endpoint. Then use an HTTP library, I prefer rest-client, to then submit the form to y.com.
I'm developing a mobile application that requires users to login, and then they can use the application. The application will submit data to the server upon submission. Here's my question: if I want the application to be available to users even when there is no internet connection, I will allow them to bypass the login screen and use the application without logging in. However, once an internet connection is available, and the application knows that, and tries to submit the information to the server (through jQuery AJAX), how do I validate the request? It seems like if someone really wanted to, they could set up their own web page and submit their own [fictitious] data to my server using the same AJAX URL and data format that my application is using. What would stop them? How do I ensure on my server side (receiving end of the AJAX request) that the only data coming in belongs to my application, and not someone who is simply mimicking my AJAX requests?
The only thing I can think of is when the application detects that the internet connection is back, immediately show the user the login screen, and then use an expiring cookie/ticket to validate the AJAX requests.
Any advice? Thanks!
I'm using VS2010,C# for developing ASP.NET. I want to send periodical messages to server in order that server knows which user is really active (with open windows), so that when a user closes window or changes url (instead of clicking on logout button), my server can detect user sign out and can close his session. what are my options here? I don't think JavaScript would be safe as I should probably update my database (is there any other way? for instance can I call an address in my JS function?)
Another solution would be to use AJAX to send server side messages to server, is it safe and efficient? what is the best way? security is really important for me
Using ajax with JQuery is a good option
Our web server uses CAS for single sign on. The CAS server is running the JASIG CAS server on https://portal.ourdomain.com and the web server is running Rails on http://service.ourdomain.com.
The Rails server has its session timeout set fairly low as a single sign-out backup measure and for other reasons. So occasionally, users do get redirected to portal.ourdomain.com for reauthentication. Normally this is seamless since portal.ourdomain.com immediately redirects them back to service.ourdomain.com with an updated ticket cookie unless the CAS session has expired.
However, this doesn't work for AJAX. Web browsers do not follow redirects for XHR requests, even if the domain is the same.
One obvious solution would be to serve everything from https://ourdomain.com and stop with the subdomain nonsense. This is an extensive operation and would require serving everything through https.
Another solution would be to regularly ping the server so that it never times out. Besides the increased load on the server, having pages that never time out defeats the purpose of having the timeout in the first place.
Which leads to the third, crappy solution: just remove the timeout.
How to Overcome Cross-domain Issues for Ajax Calls to CAS-protected Resources? is a similar question which is unanswered, but that question appears to be broader, so I hope there's an answer to our question.
Does anybody have any solutions to this problem that don't suck?
You only can wrap the ajax xhr requestwhendoing revalidation, so that the browser can understand the redirect. That would need to change code for the cas proxy.
This "work around must be checked and extended (in worst case) for every kind of ajax web framework. We did it for jquery, which gladly is ajax base for rails3.