Using ASP.NET MVC, sessions are stored in SQL database (never had a problem with them, and didn't use web farm). Using also Twitterizer2 library. Using Firefox.
First request, no browser instances is opened. Browser instance is started.
We have simple form "Publish on twitter" and submit button Share.
When Share is clicked we store message in Session and redirect to Twitter's OAuth authentication (on POST submit).
We authenticate OK and return to our Action and before posting to Twitter we check if message is stored in Session (and it isn't! - it is lost immediately after Twitter redirection)
When we try another messsage Share it is now working (Session).
We solved it using a Cookie but we don't have a clue while we lost Session (first time) after returning from Twitter.
Any deas?
I'd like to ask how did you maintained the session without cookie the first time?
I think the problem can be of the cookie set process. I also experienced similar problem before a couple of weeks.
The problem was that when I make request for REQUEST token, this request is internal HTTP request (not via user browser). As a response to this request I get REQUEST token and then set it in the user session.
$token = getRequestToken();
$_SESSION['token'] = $token;
However, if the user just came to my site for first time without a session, he does not have a session cookie to sent me. Internally at the web site I have created a session for him, and stored the token inside it, but then instead of sending him response with cookie headers included, so that he "accepts" my session, I make redirect to the provider authorize endpoint. This way, the user does not get the session cookie, and when he is returned back, he is like a new user for my site.
This is the flow of the process that happened to me:
create user session in the database
setcookie(usersession) // add headers to the eventual response
get request token
set the token in the session
redirect the user (user does not receive the session cookie)
user goes to authorization point
user returns, but he is a new user for me
I'd be interested to know if you had similar problem :)
Best regards
check the request and callback domain are the same
i.e. you are making request for oauth from localhost and callback to 127.0.0.1
Related
I've been trying to consume an authorized ASP.NET Odata Web API by using an Odata client. I do know how to set the header with the token for the client, but where should the token be kept for re-use?. Because the Authorization header has to be set with each request, not just once. To be more precise, this is what I am down to:
Get user's credentials, pass them back to the API.
Get token.
Set the header for the Odata client with the token value.
I am struggling with the actions to be taken between 2nd and 3rd step: Where should the token be kept, so you could keep setting the Odata client Header with it?
This is how I set the authorization header value.
EDIT: In regards to the comment, I might've not clearly specified the issue. The problem arises, because controllers will be created for every request and will be garbage collected "sometime after" the request has completed. So, the token value will be gone.
have a look here, they are storing it in a cookie. If you do not want to expose the actual token on the client side, store it somewhere near your e.g. user profile / session, or store the token with a generated id in a lookup-table and save the id to a cookie.
this is another approach using ASP.NET Identity and ApplicationCookies
The website use Angularjs as frontend to call API(Asp.net in IIS).
Each request passed Global.asax Start_Session generate new session ID.
It supposed to use the same session to the same user.
I am trying to send GET request with this URL:
$http({method: 'GET', url: 'http://localhost:59893/initSite.aspx'})
I read this qusetion but the answer doesn't help in my case:
ASP.NET: Session.SessionID changes between requests.
I'm not sure about ASP but with PHP I have found a similar problem with API requests. You can't rely on ASP/PHP to remember the session ID's on each request from different clients, you need to post a session ID with each request to the API where that session ID is checked against a list of logged in users in a Database.
This would be the proper way of handling logged in users with a remote API.
Check this similar answer: Auto Logout when user leaves the application without doing logout action
If you want your session Id to be same for every request for that particular session...store something in the session variable(anything dummy)...then it will give the same session id..
It happens if you don't have anything stored in your session variable..you will always get a new session id for the same session itself.
Do something like below
Session["any_name"]="anything";
I am developing a console application in C# to do some background scraping from a web site. There is no use of webbrowser, winform or ASP etc., just plain http request & response.
I have this problem of logging out the site and the session is still alive so my relogging in is rejected soon after logging out because the site only allows one concurrent user to login. I have done google research and found no clue yet.
Here is the logout code:
public HttpResult logout()
{
HttpHelper http = new HttpHelper();
HttpItem item = new HttpItem()
{
URL = "https://w w w.mysite.com/logoff",
Method = "get",
ResultCookieType = ResultCookieType.CookieCollection,
Allowautoredirect = true,
};
HttpResult res = http.GetHtml(item);
return res;
}
I have used Httpwatch to have a peek of the request/response headers as well as the cookies. What I found is that the response contains three cookies with values zeros after logging out. My impression is that in the case of a browser, these cookies gets updated so relogging in request will be redirected to login page. How can I do it like a browser does it?
The problem I encountered was due to shutdown by TerminateProcess that forced a closedown of of my main app along with the logout before it had a chance to run.
So I replace TerminateProcess with a soft close which gives signal to the logout to run properly before my main app's close. I also cancel the logout step I used before login. This way, the cookies are invalidated and stored at logout. Now if I try to login right after logout, everything is fine because of the magic in the cookies. One lesson learned is that we need to use CookieCollection in stead of simple cookie when making request. The former will take care of updating cookies in the cookie container.
I have a site (still on localhsot).
I want to authorize the user against Google and get permission to gmail scope.
I get a requestToken
Authorize it
Save requestToken from the queryString into a cookie (?)
(I don't have accessToken by now)
Upgrade it to accessToken
Then what?
I thought to save requestToken and accessToken in the DB with some user guid (?)
Are they both parmenent and uniqe?
Will it help next time to avoid the Upgrade it to accessToken
When the user come back for the second time - how will I retrieve its access token?
You will have to store the access token with the user data, yes. Then you will set the Forms Authorization cookie as normal against their username or id.
When they come back a second time, if they still have the cookie, then they will be signed in as normal.
If their cookie has expired, ask them to log in with their chosen provider (Google) and retrieve the token again. You will then have to search the data to see if any users have that token already, and if they do, log that user in as normal like you do the first time.
If they log in with a different provider, they will get a different token and will effectively be seen as a different user - how you handle this is a separate issue.
Im trying to login to a website (www.vodafone.ie) with a console app and c# httpWebRequest. Problem is it works ok about 50% of the time.
Im using fiddler to find out the GET and POST requests I need to make. Done that and my app is successfully recreating these as best as I can see. The steps are; 1) GET request with cookie container to login uri. server response sets new cookie called jsessionID 2) do POST request with login credentials and same cookie container containing previous jsessionID.
Looking at the fiddler logs for successful POST request login (browser or my app) I see it sets a thing in the response header : "Set-cookie: supercookie=-; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=". What is this supercookie thing? Its not returned to me in the response cookie collection like the jsessionID. On rare occasions, there is along string of numbers with the supercookie instead of just "-".
I made sure to clear all cookies before analyzing the request/response headers. If the super cookie thing is not being set in the reponse my login fails. So just wondering what's going on here?
cheers!
supercookie is just a name of another cookie. It's quite possible they are using that to prevent screen scraping. Make sure when you receive that response that the cookie container now holds that new supercookie cookie.