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: 295158WC_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
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: 295158WC_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
West Wind Technologies
Making waves on the Web
from Maui
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: 295158WC_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
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: 295158WC_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
West Wind Technologies
Making waves on the Web
from Maui
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: 295158WC_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
West Wind Technologies
Making waves on the Web
from Maui
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: 295158WC_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
+++ 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: 295158WC_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
West Wind Technologies
Making waves on the Web
from Maui
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: 295158WC_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
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: 295158WC_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
West Wind Technologies
Making waves on the Web
from Maui
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: 295158WC_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
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: 295158WC_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
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: 295158WC_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 ---
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: 295158WC_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
West Wind Technologies
Making waves on the Web
from Maui
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: 295158WC_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
West Wind Technologies
Making waves on the Web
from Maui
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: 295158WC_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
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: 295158WC_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
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: 295158WC_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
West Wind Technologies
Making waves on the Web
from Maui
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: 295158WC_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