Thread: [Rainbowportal-devel] Bug
Brought to you by:
danijel_kecman,
manudea
From: <Mat...@sk...> - 2003-11-19 15:06:24
|
Hi=20 I inserted a bug in august this year and figuered out today, that I have = to send an email. I have also a solution to the bug, please have a look at bug number = 786613: Authentication Windows: Assigned ADS Groups do not work I tried using windows authentication. So far everything=20 ok. But when I tried to assign active directory groups to=20 modules, the people belonging to this groups could not=20 see the modules. The problem is: By adding an ad-group in the module=20 settings, they are seperated with semicolons (;). After=20 each semicolon a space is added. That makes it more=20 readable and is ok so far. But in Security.cs this string is=20 splitted and, unfortunately, the spaces stay. So it just=20 needs a trim around every string. I did this in IsInRole()=20 and IsInRoles() and then it worked. It's not necessary=20 to do that in both, but since both are public I preferred=20 to do it. Attention: I'm still using version 1722. So if anything=20 changed at version 1733 it isn't in the file. =20 That's it, thanks Matthias SKYBOW AG Seestrasse 25 CH-8702 Zollikon=20 Switzerland Phone Direct: +41 1 396 99 04 Phone Main: +41 1 396 97 77=20 Fax: +41 1 396 97 66 Mobile: +41 79 486 06 00 E-Mail: mat...@sk... Web: www.skybow.com Privileged/Confidential Information may be contained in this message. If = you are not the addressee indicated in this message (or responsible for = delivery of the message to such a person), you may not copy or deliver = this message to anyone. In such case, you should destroy this message = and kindly notify the sender by reply email. Please advise immediately = if you or your employer does not consent to Internet email for messages = of this kind. Opinions, conclusions and other information in this = message that do not relate to the official business of my/our firm shall = be understood as neither given nor endorsed by it. |
From: Leo D. <le...@cl...> - 2004-09-28 16:28:17
|
I need to concede defeat. I have been spending a lot of time trying to find a way to fix this bug... http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D957922&group= _id =3D66837&atid=3D515929 but it is beyond my realm of expertise. If anyone else would like to tackle it feel free too. =20 Chris Hynes has offered to let us use his SlickUpload control in order to make the document upload smoother. However, it doesn't really do anything to help with this particular bug. =20 From the research that I've done there are a couple of ways that this bug can be fixed... 1. Change the <httpRuntime useFullyQualifiedRedirectUrl=3D"true" maxRequestLength=3D"4096" /> setting and increase the maxRequestLength = to a much larger number. NOTE: This doesn't fix the bug; it merely hides it in most circumstances. The main problem with this approach is as follows... a. The error is not thrown until the maxRequestLength has actually been exceeded. For example, say the maxRequestLength is 10MB, and the user is uploading a 11MB file over a slow connection. The server would throw the error once the request length hits 10MB which means that the user just wasted a lot of time while s/he tried to upload the file. 2. (The correct way) Use client side JavaScript to check the maxRequestLength setting in the web.config file. The JavaScript code could then calculate the file size BEFORE the file is uploaded, and it could alert the user that the file is too large to be uploaded to the server. =20 Because I lack the experience with creating client side scripts, and I don't have the time to learn JavaScript, I am offering this bug back to the Rainbow Community. =20 This link, offered up by David Reed, comes close to getting this feature implemented. The JavaScript will calculate the files size, and offers a good start for a JavaScript programmer to compare that value to the maxRequestLenght. http://www.faqts.com/knowledge_base/entry/edit/index.phtml?aid=3D1685=20 =20 If you decide to take this bug over, and still have questions after reading this message, please contact me. =20 Thank you, =20 Leo |
From: Chris H. <ch...@as...> - 2004-09-28 23:46:35
|
That's a feature I can add to SlickUpload. All I need to know is how to get the maxRequestLength programatically. Because the request is intercepted at the earliest possible point, it should be possible to check the ContentLength HTTP header against the maxRequestLength. If it's not possible to get the maxRequestLength property progamatically, I could at least add another SlickUpload setting. Anyone know how to retrieve the maxRequestLength property? Chris _____ From: Leo Duran [mailto:le...@cl...] Sent: Tuesday, September 28, 2004 12:28 To: rai...@li... Subject: Bug I need to concede defeat. I have been spending a lot of time trying to find a way to fix this bug. http://sourceforge.net/tracker/index.php?func=detail <http://sourceforge.net/tracker/index.php?func=detail&aid=957922&group_id=66 837&atid=515929> &aid=957922&group_id=66837&atid=515929 but it is beyond my realm of expertise. If anyone else would like to tackle it feel free too. Chris Hynes has offered to let us use his SlickUpload control in order to make the document upload smoother. However, it doesn't really do anything to help with this particular bug. >From the research that I've done there are a couple of ways that this bug can be fixed. 1. Change the <httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="4096" /> setting and increase the maxRequestLength to a much larger number. NOTE: This doesn't fix the bug; it merely hides it in most circumstances. The main problem with this approach is as follows. a. The error is not thrown until the maxRequestLength has actually been exceeded. For example, say the maxRequestLength is 10MB, and the user is uploading a 11MB file over a slow connection. The server would throw the error once the request length hits 10MB which means that the user just wasted a lot of time while s/he tried to upload the file. 2. (The correct way) Use client side JavaScript to check the maxRequestLength setting in the web.config file. The JavaScript code could then calculate the file size BEFORE the file is uploaded, and it could alert the user that the file is too large to be uploaded to the server. Because I lack the experience with creating client side scripts, and I don't have the time to learn JavaScript, I am offering this bug back to the Rainbow Community. This link, offered up by David Reed, comes close to getting this feature implemented. The JavaScript will calculate the files size, and offers a good start for a JavaScript programmer to compare that value to the maxRequestLenght. http://www.faqts.com/knowledge_base/entry/edit/index.phtml?aid=1685 If you decide to take this bug over, and still have questions after reading this message, please contact me. Thank you, Leo |
From: manudea <ma...@du...> - 2004-09-29 00:37:42
|
I think this replies: =20 http://www.help.ip3.com/m.p.d.l.csharp/G-maxRequestLength-v.shtml =20 =20 ------------------------------------ Emmanuele De Andreis Technical Manager DUEMETRI Internet Solutions Provider =20 RAINBOW PORTAL Main portal - <http://www.rainbowportal.net> = http://www.rainbowportal.net Sourceforge / CVS - <http://sourceforge.net/projects/rainbowportal/> http://sourceforge.net/projects/rainbowportal/ Support Forums - <http://www.rainbowportal.net/ASPNetForums> http://www.rainbowportal.net/ASPNetForums _____ =20 Da: rai...@li... [mailto:rai...@li...] Per conto di = Chris Hynes Inviato: mercoled=EC 29 settembre 2004 1.23 A: 'Leo Duran'; rai...@li... Oggetto: [Rainbowportal-devel] RE: Bug =20 That's a feature I can add to SlickUpload. =20 All I need to know is how to get the maxRequestLength programatically. =20 Because the request is intercepted at the earliest possible point, it = should be possible to check the ContentLength HTTP header against the maxRequestLength. If it's not possible to get the maxRequestLength = property progamatically, I could at least add another SlickUpload setting. =20 Anyone know how to retrieve the maxRequestLength property? =20 Chris |
From: Chris H. <ch...@wi...> - 2004-09-29 00:38:09
|
I figured out how to get the maxRequestLength. HttpContext.GetConfig and some reflection magic. Problem is, ASP.NET still blows up. Anybody know how to fool it into thinking it's a new request? Chris _____ From: rai...@li... [mailto:rai...@li...] On Behalf Of Chris Hynes Sent: Tuesday, September 28, 2004 19:23 To: 'Leo Duran'; rai...@li... Subject: [Rainbowportal-devel] RE: Bug That's a feature I can add to SlickUpload. All I need to know is how to get the maxRequestLength programatically. Because the request is intercepted at the earliest possible point, it should be possible to check the ContentLength HTTP header against the maxRequestLength. If it's not possible to get the maxRequestLength property progamatically, I could at least add another SlickUpload setting. Anyone know how to retrieve the maxRequestLength property? Chris _____ From: Leo Duran [mailto:le...@cl...] Sent: Tuesday, September 28, 2004 12:28 To: rai...@li... Subject: Bug I need to concede defeat. I have been spending a lot of time trying to find a way to fix this bug. http://sourceforge.net/tracker/index.php?func=detail <http://sourceforge.net/tracker/index.php?func=detail&aid=957922&group_id=66 837&atid=515929> &aid=957922&group_id=66837&atid=515929 but it is beyond my realm of expertise. If anyone else would like to tackle it feel free too. Chris Hynes has offered to let us use his SlickUpload control in order to make the document upload smoother. However, it doesn't really do anything to help with this particular bug. >From the research that I've done there are a couple of ways that this bug can be fixed. 1. Change the <httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="4096" /> setting and increase the maxRequestLength to a much larger number. NOTE: This doesn't fix the bug; it merely hides it in most circumstances. The main problem with this approach is as follows. a. The error is not thrown until the maxRequestLength has actually been exceeded. For example, say the maxRequestLength is 10MB, and the user is uploading a 11MB file over a slow connection. The server would throw the error once the request length hits 10MB which means that the user just wasted a lot of time while s/he tried to upload the file. 2. (The correct way) Use client side JavaScript to check the maxRequestLength setting in the web.config file. The JavaScript code could then calculate the file size BEFORE the file is uploaded, and it could alert the user that the file is too large to be uploaded to the server. Because I lack the experience with creating client side scripts, and I don't have the time to learn JavaScript, I am offering this bug back to the Rainbow Community. This link, offered up by David Reed, comes close to getting this feature implemented. The JavaScript will calculate the files size, and offers a good start for a JavaScript programmer to compare that value to the maxRequestLenght. http://www.faqts.com/knowledge_base/entry/edit/index.phtml?aid=1685 If you decide to take this bug over, and still have questions after reading this message, please contact me. Thank you, Leo |
From: Chris H. <ch...@wi...> - 2004-10-27 23:54:15
|
I've been researching this problem further, and there doesn't appear to be a way to stop an in-process upload without returning an error page. The only way to abort an upload would be to cut the connection, which would immediately show the error page on the client. Unless anyone knows a better way to deal with this, there are only two ways I can think of to deal with this: 1) Just cancel the upload. We could get around the error page showing by making the actual upload section of the page an IFrame, and showing a progress page while the upload is in process. We could then detect the error and show a proper message. 2) Stream the message out to nothing, then return an error at the end. This would work, but it means we still have to deal with the oversized upload. At least it won't be streaming into memory... Chris _____ From: rai...@li... [mailto:rai...@li...] On Behalf Of Chris Hynes Sent: Tuesday, September 28, 2004 20:38 To: rai...@li...; 'Leo Duran' Subject: RE: [Rainbowportal-devel] RE: Bug I figured out how to get the maxRequestLength. HttpContext.GetConfig and some reflection magic. Problem is, ASP.NET still blows up. Anybody know how to fool it into thinking it's a new request? Chris _____ From: rai...@li... [mailto:rai...@li...] On Behalf Of Chris Hynes Sent: Tuesday, September 28, 2004 19:23 To: 'Leo Duran'; rai...@li... Subject: [Rainbowportal-devel] RE: Bug That's a feature I can add to SlickUpload. All I need to know is how to get the maxRequestLength programatically. Because the request is intercepted at the earliest possible point, it should be possible to check the ContentLength HTTP header against the maxRequestLength. If it's not possible to get the maxRequestLength property progamatically, I could at least add another SlickUpload setting. Anyone know how to retrieve the maxRequestLength property? Chris _____ From: Leo Duran [mailto:le...@cl...] Sent: Tuesday, September 28, 2004 12:28 To: rai...@li... Subject: Bug I need to concede defeat. I have been spending a lot of time trying to find a way to fix this bug. http://sourceforge.net/tracker/index.php?func=detail <http://sourceforge.net/tracker/index.php?func=detail&aid=957922&group_id=66 837&atid=515929> &aid=957922&group_id=66837&atid=515929 but it is beyond my realm of expertise. If anyone else would like to tackle it feel free too. Chris Hynes has offered to let us use his SlickUpload control in order to make the document upload smoother. However, it doesn't really do anything to help with this particular bug. >From the research that I've done there are a couple of ways that this bug can be fixed. 1. Change the <httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="4096" /> setting and increase the maxRequestLength to a much larger number. NOTE: This doesn't fix the bug; it merely hides it in most circumstances. The main problem with this approach is as follows. a. The error is not thrown until the maxRequestLength has actually been exceeded. For example, say the maxRequestLength is 10MB, and the user is uploading a 11MB file over a slow connection. The server would throw the error once the request length hits 10MB which means that the user just wasted a lot of time while s/he tried to upload the file. 2. (The correct way) Use client side JavaScript to check the maxRequestLength setting in the web.config file. The JavaScript code could then calculate the file size BEFORE the file is uploaded, and it could alert the user that the file is too large to be uploaded to the server. Because I lack the experience with creating client side scripts, and I don't have the time to learn JavaScript, I am offering this bug back to the Rainbow Community. This link, offered up by David Reed, comes close to getting this feature implemented. The JavaScript will calculate the files size, and offers a good start for a JavaScript programmer to compare that value to the maxRequestLenght. http://www.faqts.com/knowledge_base/entry/edit/index.phtml?aid=1685 If you decide to take this bug over, and still have questions after reading this message, please contact me. Thank you, Leo |