|
okay, see that was just a little part of my class. Actually im reading the images like this
BL = new Bitmap(new MemoryStream(tmp_br.ReadBytes(tmp_br.ReadInt32())));
Since i wrote that code(in first post) in CodeProject, so i thought to write Image.FromFile()
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
|
|
|
|
|
No it won't leak as such. You have to try pretty hard to get .NET to leak properly.
Image is disposable though, so you might want to dispose of images when you're done with them otherwise they might hang around longer than you want. (that'd release the file too).
Regards,
Rob Philpott.
|
|
|
|
|
yeah i went down the dispose route at first when using .FromFile() but found it more hassle then creating one function that returns an Image from a stream by passing the filepath
My opinion is... If someone has already posted an answer, dont post the SAME answer
|
|
|
|
|
yes 
http://www.codeproject.com/script/Forums/View.aspx?fid=1649&msg=2912374
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
|
|
|
|
|
Try use Using keyword. It will dispose object. Read more in MSDN about Using keyword.
|
|
|
|
|
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 
|
|
|
|
|
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
|
|
|
|
|
Simple, but fairly easyto brute-force from an (in)security point of view.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Then what is your better solution?
regards,
George
|
|
|
|
|
Good solution, musefan!
regards,
George
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Thanks for viewing, actually this is a word automation question but please read on
I have Office 2007 installed on my development machine, and a need for my application to generate word reports (a pain in itself), but that i can manage.
What I want to do is make sure it works using Office 2003, which at the minute it does not (tested on another machine with Office 2003 installed).
Now from what i have found trawling the net is that i can get backwards compatibility if i work with the Microsoft Word 11.0 Object Library (2003)
Does anybody now a way to get these .dll files without installing Office 2003 on my dev machine?
Or an alternative to needing an earlier version of the library for backwards compatability
Thanks
My opinion is... If someone has already posted an answer, dont post the SAME answer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
