We are migrating from ColdFusion 8 to 10. Our application is having functionality written in .NET as well however the session is maintained in ColdFusion only.
Current architecture in ColdFusion 8 for .NET and CF integration:
Session is set when user logs in to the app (In CF). (We are using J2EE sessions.)
When a user clicks on a .NET link, Jsessionid,CFID and CFTOKEN are passed to .net page via url. Inside .net code the following steps are done to check session:
2a. Call a common function which will do a ColdFusion file request (chkSession.cfm) with jsessionid in url.
2b. chkSession.cfm will return session.UID if available else will return -1. Session.UID will be available if the jsessionid in url is valid.
2c. .NET page will be loaded if a valid UID is returned. User will be redirected to login page if -1 is returned.
Issue in CF 10:
In CF 10 , always we are getting -1. I read that as part of security enhancement in CF 10, we will not be able to recreate a ColdFusion session by passing cfide, cftoken, jsessionid in the url.
I would like to get your advice on what is the best way to make our .NET functionalties work in ColdFusion 10. Is there any better way to check ColdFusion session from .NET ?
One option I can think of is using a database. I looking forward to a solution that can be implemented quickly and is robust.
What I think would work would be to change your .Net client code to send over the JSessionID as a cookie value in its request. That way the functionality you have ought to work again.
It's worth noting that exposing the Session ID in URLs can expose you to certain security vulnerabilities, so it may be something you want to look at avoiding in future.
I have used the database approach you mention also. If you go this route, have the CF code insert a record using a GUID as an identifier and a timestamp for when the record was created. On the .Net side, look up the GUID and only accept the request if the timestamp is from less than X seconds ago, so you don't create a token which will authenticate you for a long time. X needs to be the max ammount of time you think it'll take a client to follow the redirect from CF to the .Net pages, so 2 is likely plenty.
You will want to delete used tokens and have a scheduled task to delete 'unused' tokens.
Related
I have an application hosted in Azure using Azure Active Directory and OpenIDConnect for authentication - generally all works well. However I'm having an issue where some requests generate a call to https://login.microsoftonline.com/ and then on to the requested page - no password is requested. I'm assuming that this is some kind of token refresh?
The problem is that the site uses a fair amount of ajax and these requests stop working because they get redirected to https://login.microsoftonline.com/ This happens after maybe 15 minutes, however the nbf and exp properties of the JWT token show a validity period of approximately an hour.
I've set the BackchannelTimeout property of OpenIdConnectAuthenticationOptions to 30 minutes, however this doesn't seem to have made any difference.
Can anyone offer any advice on what may be happening and the options to change or work around the behaviour?
Your question can be answered in the same way as this other thread: MVC AD Azure Refresh Token via ADAL JavaScript Ajax and KnockoutJs
In short: the OpenId Connect middleware is designed to support redirect based web applications. Ajax calls are not well suited to be protected via cookies, and the issue you are experiencing is one of the reasons why. Javascript based API calls are better protected using tokens rather than cookies.
For some links that might provide an alternative approach, see the link above.
I created a nuget package for .NET web applications which is refreshing the Azure Active Directory Token in the background.
More info: https://www.nuget.org/packages/RefreshTokenForAjaxRequest.Azure.ActiveDirectory/
I'm working with an old ASP.NET application which has lots of lousy code.
I have been mostly a winform developer and my knowledge of webforms is still limited.
However looking at code the way the developer tried to pass information to other pages sound invalid to me.
Here is a typical way he passes info from one page to other page:
Response.Redirect("ABC.aspx?SessionID=08F7DCF3D6984EC984F6580A4EC7E9C2&CID=" _
& e.Item.Cells(iColClientID).Text & "", True)
Then on other pages he uses Request.QueryString to get the data back:
Request.QueryString
My question is why in the world he needs to also pass a Hardcoded SessionID=08F7DCF3D6984EC984F6580A4EC7E9C2 in the query string.
Web.config shows :
<sessionState mode="InProc" cookieless="false" timeout="30"/>
So if session is using cookies why send session id?
To me code is written by an amature developer. Please provide your feedback.
Unless he uses the SessionID parameter for something else -some other obscure logic in there that relies on it being present in the QueryString-, there's no reason to put a SessionID in the query string at all. With or without cookies enabled how to get the SessionID should be transparent to you and it suffices to do:
var sessionID = Session.SessionID;
Some relevant documentation from MSDN regarding cookieless sessions (which is not the case here according to the Web.config you showed):
ASP.NET maintains cookieless session state by automatically inserting
a unique session ID into the page's URL. For example, the following
URL has been modified by ASP.NET to include the unique session ID
lit3py55t21z5v55vlm25s55:
http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx
When ASP.NET sends a page to the browser, it modifies any links in the
page that use an application-relative path by embedding a session ID
value in the links. (Links with absolute paths are not modified.)
Session state is maintained as long as the user clicks links that have
been modified in this manner. However, if the client rewrites a URL
that is supplied by the application, ASP.NET may not be able to
resolve the session ID and associate the request with an existing
session. In that case, a new session is started for the request.
I have a Spring 3 MVC app and part of the app requires a redirect to a 3rd party payment site and that payment site redirects back to my app after it's done. The problem is that Spring seems to create a new session instead of using the old one and erases all the data previously stored in the session. This creates massive problems for my app and I'm wondering if there is a way to preserve the session after external redirect?
Also, cookie are enabled on my browser and I indeed verified that the jsessionid value in the cookie changes after the redirect, indicating a new session overwriting the old one.
Can you provide the following info:
After coming back from the 3rd party site, does your app use a different domain/sub domain from what it uses before redirecting to the 3rd party site?
Is there a possibility that your session timeout value is so low that the session expires by the time the user returns to your app?
Does your app use frames having onunload events that invalidate the session?
Here is the situation, I have setup 2 codeigniter installation.
One will be a client and one will be an api. Further improvement of this will be
The client will no longer be made from CI, since I wasn't using it's functionality. I just wanted to start out from a mvc framework right on.
My question would be where should I be storing sessions? during logins.
Below is how I did it, but I think I did it wrong.
I created a Login from the client. This one sends the login credentials to the api and then validated these information sent by the client and will return a message/response whethere the login credentials were valid or not.
If the login details were valid, the api will set a session in it's controller like this
if(true) {
$this->session->set_userdata($array);
}
This is in the login_controller I created. Is this the proper way of setting sessions for a client of a api?
You've got the concept right. You only want to set session userdata upon verifying the user supplied valid credentials.
That said, make sure you're using encrypted cookies and, if you're handling sensitive data, store your session data in the database. Storing it in the database causes some odd quirks with how sessions work in CodeIgniter (mainly with flashdata), but the added benefit of positive identification might potentially be worth it.
By storing the session data in the database, you can more positively verify a user is who they claim to be (in terms of the session ID, etc). The reason is because the session data is stored only in the database, and not in the session cookie (which only holds session ID and some other info). That way, even if someone does manage to decrypt the cookie, they can't modify their userdata to pretend to be someone else, like you might be able to with the cookies only method.
Classic ASP creates cookies with name something like ASPSESSIONIDSSDSQQCR where suffix after "ASPSESSIONID" is different.
If you work for some time with application browser keeps storing all previous session cookies (could be 10 cookies or more), so there is no way to understand which cookie is for the current session
I know there is a way to get current SessionID
Session.SessionID
but how can I get a cookie value as well?
I'm just trying to create authentication solution for ASP.NET which is just addon for Main Classic ASP application.
In that design main application creates record in database with current Classic ASP cookie value and after that when user tries to access ASP.NET part, it just takes all "ASPSESSIONIDSSD+XXXXX" cookies in request and verifies which one of them is still valid by looking for initial record in database. If valid session found then it should initiate ASP.NET session....
I don't think you can get Classic ASP's Session ID cookie from ASP.NET. The Classic ASP session cookie has crypto applied to prevent your clients from tinkering with it. Unfortunately, this also prevents your .NET code from tinkering with the session cookie.
The easiest thing I can think of is to set an additional cookie in your Classic ASP code. Rather than storing the Classic Session ID in your database, store some other key, like a GUID. Then send a session cookie to the browser with the key.
Response.Cookies("SessionKey") = GeneratedGuid
You can then read the SessionKey cookie in .NET and lookup its value from the database.