how to send user ID across differnet application in ASP.Net?
-
Hello everyone, I have two web applications all are developed by ASP.Net. Now I want to provide a feature which enables the user to click from one URL in application site (one virtual directory of IIS) A to the other URL in application site B (another virtual directory of IIS). I have two ideas to implement them, but both of them have issues. I want to know what solution should be optimum solution? Solution 1: using cookie, so from both application sites, we could retrieve user ID information from reading cookie, but I am afraid if cookie is disabled in browser, this "jump" feature never works. Solution 2: When the user redirects to an URL in another site, I could append user ID after the URL, I could redirect to this URL in another site http://www.anotherapplicationsite.com/somesuburl?userID=foo, but I am afraird that in this way userID will be exposed easily which raise security issues. Any advice? thanks in advance, George
-
Hello everyone, I have two web applications all are developed by ASP.Net. Now I want to provide a feature which enables the user to click from one URL in application site (one virtual directory of IIS) A to the other URL in application site B (another virtual directory of IIS). I have two ideas to implement them, but both of them have issues. I want to know what solution should be optimum solution? Solution 1: using cookie, so from both application sites, we could retrieve user ID information from reading cookie, but I am afraid if cookie is disabled in browser, this "jump" feature never works. Solution 2: When the user redirects to an URL in another site, I could append user ID after the URL, I could redirect to this URL in another site http://www.anotherapplicationsite.com/somesuburl?userID=foo, but I am afraird that in this way userID will be exposed easily which raise security issues. Any advice? thanks in advance, George
George_George wrote:
Solution 1
Wont work, cookies are only sent to the same domain that created them for obvious security reasons. If both applications resided within the same domain but were, say, subdirectories of that main root then your in with a chance of this solution!
George_George wrote:
Solution 2
Is terribly insecure how you described it. If you have to do it this way, you need to generate something long (like a Guid) for each session and pass this between apps. You MUST make sure these sessions are time limited, and cannot be used after a session has finished. This is no small feat, and requires alot of bespoke code to handle session management, and the criteria for which they can acceptably be passed between 2 apps. One other solution you could consider is using NT Security in both applications, as the currently logged on user is easy to obtain in ASP.NET or a winforms app - this would negate the need for much of your user management code, and allow you to still know who is currently logged in. This solution kind of relies on your applications residing on one network, where all users can be added to your domain server(s). You're getting better at asking questions my old friend ;) This one showed some actual though (and maybe a little research) on your part :omg:
-
Hello everyone, I have two web applications all are developed by ASP.Net. Now I want to provide a feature which enables the user to click from one URL in application site (one virtual directory of IIS) A to the other URL in application site B (another virtual directory of IIS). I have two ideas to implement them, but both of them have issues. I want to know what solution should be optimum solution? Solution 1: using cookie, so from both application sites, we could retrieve user ID information from reading cookie, but I am afraid if cookie is disabled in browser, this "jump" feature never works. Solution 2: When the user redirects to an URL in another site, I could append user ID after the URL, I could redirect to this URL in another site http://www.anotherapplicationsite.com/somesuburl?userID=foo, but I am afraird that in this way userID will be exposed easily which raise security issues. Any advice? thanks in advance, George
Cookies are not difficult to expose either thou so... what about when a user logs in you create a random key and store that on the server so you can identify the user. That could be passed in the URL and would be different each time Ive never done it, so just a suggestion.
My opinion is... If someone has already posted an answer, dont post the SAME answer
-
Hello everyone, I have two web applications all are developed by ASP.Net. Now I want to provide a feature which enables the user to click from one URL in application site (one virtual directory of IIS) A to the other URL in application site B (another virtual directory of IIS). I have two ideas to implement them, but both of them have issues. I want to know what solution should be optimum solution? Solution 1: using cookie, so from both application sites, we could retrieve user ID information from reading cookie, but I am afraid if cookie is disabled in browser, this "jump" feature never works. Solution 2: When the user redirects to an URL in another site, I could append user ID after the URL, I could redirect to this URL in another site http://www.anotherapplicationsite.com/somesuburl?userID=foo, but I am afraird that in this way userID will be exposed easily which raise security issues. Any advice? thanks in advance, George
make a database to store that user id or use xml if its just user id... its your choice. SQL Database is more secured
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L %^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2 W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN% Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia> -------------------------------------------------------- 128 bit encrypted signature, crack if you can
-
George_George wrote:
Solution 1
Wont work, cookies are only sent to the same domain that created them for obvious security reasons. If both applications resided within the same domain but were, say, subdirectories of that main root then your in with a chance of this solution!
George_George wrote:
Solution 2
Is terribly insecure how you described it. If you have to do it this way, you need to generate something long (like a Guid) for each session and pass this between apps. You MUST make sure these sessions are time limited, and cannot be used after a session has finished. This is no small feat, and requires alot of bespoke code to handle session management, and the criteria for which they can acceptably be passed between 2 apps. One other solution you could consider is using NT Security in both applications, as the currently logged on user is easy to obtain in ASP.NET or a winforms app - this would negate the need for much of your user management code, and allow you to still know who is currently logged in. This solution kind of relies on your applications residing on one network, where all users can be added to your domain server(s). You're getting better at asking questions my old friend ;) This one showed some actual though (and maybe a little research) on your part :omg:
-
Could you not just create a hash of the (userID + logginDateTimeString) and store that in database along with an expiary DateTime? - Thats fairly simple
My opinion is... If someone has already posted an answer, dont post the SAME answer
-
then throw in a salt value. it would take a while to brute force attack it anyway. plus the only valuable info in the hash would be a userID value i.e. 1, 34 or 103 which is useless if it cannot be used anywhere. no?
My opinion is... If someone has already posted an answer, dont post the SAME answer
-
George_George wrote:
Solution 1
Wont work, cookies are only sent to the same domain that created them for obvious security reasons. If both applications resided within the same domain but were, say, subdirectories of that main root then your in with a chance of this solution!
George_George wrote:
Solution 2
Is terribly insecure how you described it. If you have to do it this way, you need to generate something long (like a Guid) for each session and pass this between apps. You MUST make sure these sessions are time limited, and cannot be used after a session has finished. This is no small feat, and requires alot of bespoke code to handle session management, and the criteria for which they can acceptably be passed between 2 apps. One other solution you could consider is using NT Security in both applications, as the currently logged on user is easy to obtain in ASP.NET or a winforms app - this would negate the need for much of your user management code, and allow you to still know who is currently logged in. This solution kind of relies on your applications residing on one network, where all users can be added to your domain server(s). You're getting better at asking questions my old friend ;) This one showed some actual though (and maybe a little research) on your part :omg:
Thanks J4amieC, One more question about your reply, "If both applications resided within the same domain but were, say, subdirectories of that main root then your in with a chance of this solution!" -- what do you mean this? Could you show me a sample please? Sorry I read a couple of times but can not understand what do you mean. For other parts of your reply, they are so great and I think I understand. :-) regards, George
-
Could you not just create a hash of the (userID + logginDateTimeString) and store that in database along with an expiary DateTime? - Thats fairly simple
My opinion is... If someone has already posted an answer, dont post the SAME answer
Good solution, musefan! regards, George
-
Then what is your better solution? regards, George
-
then throw in a salt value. it would take a while to brute force attack it anyway. plus the only valuable info in the hash would be a userID value i.e. 1, 34 or 103 which is useless if it cannot be used anywhere. no?
My opinion is... If someone has already posted an answer, dont post the SAME answer
"then throw in a salt value. it would take a while to brute force attack it anyway." -- intersted in this, could you show me what do you mean salt value please? :-) happy weekend, George
-
Cookies are not difficult to expose either thou so... what about when a user logs in you create a random key and store that on the server so you can identify the user. That could be passed in the URL and would be different each time Ive never done it, so just a suggestion.
My opinion is... If someone has already posted an answer, dont post the SAME answer
Cool, musefan! "Cookies are not difficult to expose either thou" -- could you show me more information please? Any documents or your experience proves some ways to expose cookie information? regards, George
-
make a database to store that user id or use xml if its just user id... its your choice. SQL Database is more secured
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L %^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2 W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN% Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia> -------------------------------------------------------- 128 bit encrypted signature, crack if you can
Why cookie is not secured? regards, George
-
Why cookie is not secured? regards, George
cookies saves on client side. And server side is more secure than client side
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L %^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2 W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN% Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia> -------------------------------------------------------- 128 bit encrypted signature, crack if you can
-
cookies saves on client side. And server side is more secure than client side
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L %^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2 W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN% Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia> -------------------------------------------------------- 128 bit encrypted signature, crack if you can
Thanks, Xmen! I agree with you on server side is more secure. But I think cookie is encrypted on client side always? So, it should also be ok? regards, George
-
Thanks, Xmen! I agree with you on server side is more secure. But I think cookie is encrypted on client side always? So, it should also be ok? regards, George
dude, encryption can be cracked easily.
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L %^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2 W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN% Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia> -------------------------------------------------------- 128 bit encrypted signature, crack if you can
-
dude, encryption can be cracked easily.
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L %^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2 W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN% Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia> -------------------------------------------------------- 128 bit encrypted signature, crack if you can
Hi Xmen, Could you show me how unsecure even if we encrypt cookie at client side? Either your experience or other documents are fine. Previous I fully trust encrypted cookie is secure and very hard (not impossible) to hack. :-) regards, George
-
"then throw in a salt value. it would take a while to brute force attack it anyway." -- intersted in this, could you show me what do you mean salt value please? :-) happy weekend, George
a salt is basically just a static string that you append to other information before hashing i.e. string salt = "SALTVALUE"; string password = "PASSWORD"; string combined = salt + password; Hash(Combined); now the hashed value is not simply the password, so it makes it harder to crack
My opinion is... If someone has already posted an answer, dont post the SAME answer
-
Cool, musefan! "Cookies are not difficult to expose either thou" -- could you show me more information please? Any documents or your experience proves some ways to expose cookie information? regards, George
well you can use the WebBrowser control, then view the cookies with the following WebBrowser.Document.Cookie //this is a string of cookies for the loaded page, they are split with ;
My opinion is... If someone has already posted an answer, dont post the SAME answer