Web Connection
Response.DownloadFile() produces 500 Internal Server Error
Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  All
  Sep 26, 2014 @ 11:31am
I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  Rick Strahl
  Steve Finch
  Sep 26, 2014 @ 12:15pm
Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve



Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  Rick Strahl
  Sep 26, 2014 @ 02:23pm
Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve




Steve

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  Rick Strahl
  Steve Finch
  Sep 27, 2014 @ 01:49am
Steve,

Turns out there was a bug in Web Connection. IIS will cause security errors if you don't have access, but if you provide a full path and you do have rights it will in fact transfer the file.

Fixed in the Web Connection module for the future...

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve






Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  Rick Strahl
  Steve Finch
  Sep 27, 2014 @ 02:22am
If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve






Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  Rick Strahl
  Sep 28, 2014 @ 08:09am
Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve







Steve

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  Rick Strahl
  Steve Finch
  Sep 29, 2014 @ 03:23pm
Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve









Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  Rick Strahl
  Sep 30, 2014 @ 12:09pm
Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve









Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  Rick Strahl
  Jim M
  Sep 30, 2014 @ 05:12pm
It's a bug - it should be Response.AppendHeader()... you can change that code in wwProcess.

I just went through and changed the code throughout Web Connection - there were two places left (all in legacy functions otherwise) that haven't been updated to the latest version.

Fixed thanks.

+++ Rick ---


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve












Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  Rick Strahl
  Oct 1, 2014 @ 06:06am
Thanks Rick... I noticed you said you are going to release another version of wconnect... Is it going to support ODATA? Is this a major release? I know it's a lot of work on your end.. Is there a list of the new features? We are willing to pay for any type of release you have in mind...

Thanks
Jim


It's a bug - it should be Response.AppendHeader()... you can change that code in wwProcess.

I just went through and changed the code throughout Web Connection - there were two places left (all in legacy functions otherwise) that haven't been updated to the latest version.

Fixed thanks.

+++ Rick ---


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve












Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  Jim M
  Oct 1, 2014 @ 06:51am
logout doesn't log out
when calling THIS.Authenticate("LOGOUT")
Doesn't seem to be clearing the authorization header


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve










Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  Jim M
  Oct 1, 2014 @ 07:00am
when calling authraw() it also gives an error ...


FUNCTION AuthRaw()

*** Retrieve actual Authenticated Username
lcUsername = Request.GetAuthenticatedUser() && use for display

*** Check to see if auth user matches our constraints
*** This is simplistic - only checks that ANY user
*** is authenticated.
IF !EMPTY(lcUserName)
*** Force Authentication Dialog
Response.Authenticate() <<------- authenticate not found

*** And exit this request since above generated
*** full HTTP document
RETURN
ENDIF


logout doesn't log out
when calling THIS.Authenticate("LOGOUT")
Doesn't seem to be clearing the authorization header


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve











Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  Rick Strahl
  Jim M
  Oct 1, 2014 @ 03:20pm
There's going to be a 5.70 release. I'm still working on it as I'm adding a new sample for the REST service functionality and cleaning up various issues etc. It's taking a little longer than expected so it'll probably be next week.

+++ Rick ---



Thanks Rick... I noticed you said you are going to release another version of wconnect... Is it going to support ODATA? Is this a major release? I know it's a lot of work on your end.. Is there a list of the new features? We are willing to pay for any type of release you have in mind...

Thanks
Jim


It's a bug - it should be Response.AppendHeader()... you can change that code in wwProcess.

I just went through and changed the code throughout Web Connection - there were two places left (all in legacy functions otherwise) that haven't been updated to the latest version.

Fixed thanks.

+++ Rick ---


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve















Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  Rick Strahl
  Jim M
  Oct 1, 2014 @ 03:20pm

Windows Authentication and Basic auth can't clear authorization headers because the browser auto-sends those. Cookie based authentication allows for true logout.

However, your app can easily handle this. If you track user authentication in your app you can have the app revoke rights for that user you're mapping to and re-enable access only on the next login. The point being - don't rely on the auth header alone to validate a user, but use something app specific in addition. This avoids a number of other issues such as injected/replayed headers as well - more secure.

+++ Rick ---



logout doesn't log out
when calling THIS.Authenticate("LOGOUT")
Doesn't seem to be clearing the authorization header


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve













Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  Rick Strahl
  Oct 2, 2014 @ 05:54am
Nice!!


There's going to be a 5.70 release. I'm still working on it as I'm adding a new sample for the REST service functionality and cleaning up various issues etc. It's taking a little longer than expected so it'll probably be next week.

+++ Rick ---



Thanks Rick... I noticed you said you are going to release another version of wconnect... Is it going to support ODATA? Is this a major release? I know it's a lot of work on your end.. Is there a list of the new features? We are willing to pay for any type of release you have in mind...

Thanks
Jim


It's a bug - it should be Response.AppendHeader()... you can change that code in wwProcess.

I just went through and changed the code throughout Web Connection - there were two places left (all in legacy functions otherwise) that haven't been updated to the latest version.

Fixed thanks.

+++ Rick ---


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve















Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  Rick Strahl
  Oct 2, 2014 @ 05:56am
Thanks Rick!

Windows Authentication and Basic auth can't clear authorization headers because the browser auto-sends those. Cookie based authentication allows for true logout.

However, your app can easily handle this. If you track user authentication in your app you can have the app revoke rights for that user you're mapping to and re-enable access only on the next login. The point being - don't rely on the auth header alone to validate a user, but use something app specific in addition. This avoids a number of other issues such as injected/replayed headers as well - more secure.

+++ Rick ---



logout doesn't log out
when calling THIS.Authenticate("LOGOUT")
Doesn't seem to be clearing the authorization header


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve













Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  Rick Strahl
  Jim M
  Oct 2, 2014 @ 03:49pm
Actually I should rephrase that. You can't effectively log out with Windows Auth or Basic Auth, but you can return a 401 request which will immediately re-prompt for re-authentication. At that point they are logged out, but you also get the login dialog again. Usually that's not desirable, but it will clear out the headers.

IMHO, the best way to do this is to always use a session var to hold auth state. If you use basic or windows auth you check for the authentication headers first and if they are there you also check the session var and if it's there, then you allow the user in. Otherwise you assume they're not authorized and kick back a 401 error which forces reauthentication or you send them to a specific logon page.

In general I find that Windows/Basic auth in applications is useful only as an all or nothing access mechanism for things like admin pages etc. It's not good for granular security and too tough to manage. Using 'Custom' authentication via UserSecurity mode is usually a better way and hooks into your own user store more easily - most apps have to map logins to users anyway, so this seems to make more sense in the first place.

+++ Rick ---


Thanks Rick!

Windows Authentication and Basic auth can't clear authorization headers because the browser auto-sends those. Cookie based authentication allows for true logout.

However, your app can easily handle this. If you track user authentication in your app you can have the app revoke rights for that user you're mapping to and re-enable access only on the next login. The point being - don't rely on the auth header alone to validate a user, but use something app specific in addition. This avoids a number of other issues such as injected/replayed headers as well - more secure.

+++ Rick ---



logout doesn't log out
when calling THIS.Authenticate("LOGOUT")
Doesn't seem to be clearing the authorization header


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve
















Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Response.DownloadFile() produces 500 Internal Server Error
  n/a
  Rick Strahl
  Oct 3, 2014 @ 06:16am
I've decided to use this:

strDomain = "shields-e"
Public PrimDomainContr
Create Cursor names (username c(30),fullname c(80),description c(80),Class c(50),accdisable l,;
acclocked l,profile c(30),loginscript c(50),Homedir c(30))
PrimDomainContr = Getobject("WinNT://" + strDomain)
For Each User In PrimDomainContr
If User.Class = 'User'
Insert Into names (username,fullname,description,Class,accdisable,acclocked,profile,;
loginscript,Homedir) Values (UPPER(User.Name),user.fullname,User.description,User.Class,User.AccountDisabled,;
User.IsAccountLocked,User.Profile,User.loginscript,User.Homedirectory)
Endif
Next


I pass the userid and password to wconnect then run the above code... It checks to see if the user exists in the domain.. if it does.. and account is not disabled.. I then check a password file for that user and see if password is correct... If everything is fine.. I pass a key back to the client that gets stored in var usess = window.sessiomStorage("usess",key) ... If the user needs to log out... I just delete the window.sessiomStorage("key") ... any time this key is not found.. the user will need to log on...

Thanks Rick,

JimM


Actually I should rephrase that. You can't effectively log out with Windows Auth or Basic Auth, but you can return a 401 request which will immediately re-prompt for re-authentication. At that point they are logged out, but you also get the login dialog again. Usually that's not desirable, but it will clear out the headers.

IMHO, the best way to do this is to always use a session var to hold auth state. If you use basic or windows auth you check for the authentication headers first and if they are there you also check the session var and if it's there, then you allow the user in. Otherwise you assume they're not authorized and kick back a 401 error which forces reauthentication or you send them to a specific logon page.

In general I find that Windows/Basic auth in applications is useful only as an all or nothing access mechanism for things like admin pages etc. It's not good for granular security and too tough to manage. Using 'Custom' authentication via UserSecurity mode is usually a better way and hooks into your own user store more easily - most apps have to map logins to users anyway, so this seems to make more sense in the first place.

+++ Rick ---


Thanks Rick!

Windows Authentication and Basic auth can't clear authorization headers because the browser auto-sends those. Cookie based authentication allows for true logout.

However, your app can easily handle this. If you track user authentication in your app you can have the app revoke rights for that user you're mapping to and re-enable access only on the next login. The point being - don't rely on the auth header alone to validate a user, but use something app specific in addition. This avoids a number of other issues such as injected/replayed headers as well - more secure.

+++ Rick ---



logout doesn't log out
when calling THIS.Authenticate("LOGOUT")
Doesn't seem to be clearing the authorization header


Also Response.AddHeader() gives "addheader not found"


Thanks for reporting this - I had long misdiagnosed this as IIS not allowing it. This is a pretty useful fix actually as it makes it much easier to push data to the client.

+++ Rick ---



Rick,

Thanks so much for taking a look at this. Just gave it a test and it seems to work fine!

I really appreciate your help.

Steve



If you want to try out the update that removes the limitation in TransmitFile() you can download:

http://west-wind.com/files/WebConnectionExperimental.zip

It includes WebConnectionModule.dll which you replace in your BIN folder.

+++ Rick ---



Hi Rick,

Thanks very much! It hadn't dawned on me that IIS might be imposing that restriction. I worked around it by copying the file to a temp location under the virtual, then using DeleteFiles() to clean up after.

Steve


Hi Steve,

TransmitFile doesn't allow downloading files outside of the Web folder. This is an IIS limitation - TransmitFile hands off the file processing to ultra efficient file serving through IIS, but it only works within the virtual folder structure of the active Web site.

If you need to pass files from other locations you can either redirect to that file (if it does exist in some web structure) or you have to stream the file yourself using FILETOSTR() and Response.Write().

+++ Rick ---



I'm in urgent need of a little help. The application I'm working on is an Engineering Data Management system that provides version and access control to documents.

I'm developing a simple API using wwRestProcess to serve up JSON data to a GIS website and that's working well. Because the document files themselves are no accessible through a Web virtual or network share (they are controlled exclusively by the application), I need to return a document file (PDF, etc.) to the client web browser from a method.

I'm using Reponse.DownloadFile() to return the document file to the client.

Response.DownloadFile(l_cPath, "application/pdf", JUSTSTEM(ALLTRIM(l_cOrigName))+"."+JUSTEXT(l_cOrigName))

I have a call that was working fine, but now I can't seem to get the browser to receive the file successfully. I get a 500 - Internal Server Error on every call. If I display the response files from the WC server, I see:

HTTP/1.1 200 OK
Content-Type: application/pdf
RequestId: 6_d54ec7be
Content-Disposition: attachment; filename=0103A3001AB-1.pdf
Content-Length: 295158

WC_TRANSMITFILE: C:\VaultixShelves\Pub\0103A3001AB-1[000003~].pdf


I've double-checked the obvious, but could have still missed something. The file exists at that path on the server, permissions seem to be correct, etc.

I did have this method in my wwRestProcess class, but thought that might be the problem, so I created a new Process class and moved this one method there, but I get the same results.

In case it makes a difference, I'm using the .NET handler instead of wc.dll.

Obviously, I'm missing something...

Thanks!

Steve
















© 1996-2024