one for the web developers - query strings (or not!)

[#1]

---

@kjpetrie wrote:

I have to say this strikes me as terribly insecure. Surely, the correct page should be selected server-side according to the user's identity and not simply passed as a redirection to the browser. Does the redirected page check the identity of the person accessing it? Otherwise, what's to stop someone trying different query strings to see other people's pages?

---

hence putting it inside an iframe so they don't see any query strings.
this login script is already in place and not something that can be changed.
it's mostly internal use only though, so security isn't that much of an issue.
and there are other checks in places on the other pages that would stop various things happening should someone change a value in a query string.

[#2]

---

@7up wrote:

This.

You say after logging in the script checks the users permissions and redirects accordingly.. why not just run the appropriate code directly after the user has logged in? - You're over complicating things using an iframe.

But.. if you've really got to continue down that road.. does the server you're using (presumably IIS) support anything like apaches rewrite module? - You could always just rewrite the url and have the script parse details from the url. I'm working on a site that has around 800 static html pages and putting them all into the database with unique addresses that all go via a rewrite rule to one php file but thats on a linux / apache setup..

---

as it's a windows server with IIS, so apache wouldn't be supported.
besides, i'm not tasked with re-creating the whole thing, just implementing the desired changes.

[#3]

---

@Anonymous wrote:

That would be on this line:

Session("blnIsUserGood") = True

I see no reason as to why you can’t also add :

Session("userName") = strUserName
Session("moreStuf") = myStuff
...

Then later in another page :

Dim sessUser As String 
sessUser = Session(“userName”)

to extract and values assign the variables. Of course you don't need to assign them to variables you could simply use the values as is e.g.

If (StrComp(Session("userType"), "Admin", vbTextCompare) == 0) THEN
    Do Admin Stuff
End If

---

this has worked a treat!

[#4]

You could still very easily find the URL for the iframe and then just plug that into a browser and change it, hence the insecurities.

As for IIS and mod_rewite it is possible.  If you have a quick google you'll find lots on it.

[#5]

true.
but unless they also guessed the correct values for the various (and there are quite a few) query string values then the real page wouldn't do anything.

[#6]

---

@chenks76 wrote:

---

---

as it's a windows server with IIS, so apache wouldn't be supported.

---

Apache does run on windows... (you probably already know that though) but as an alternative you could always run apache and have it use a (reverse) proxy pass so that requests for certain things are passed through to IIS. I had a setup like this years ago (can't remember how its done now) where most stuff was served via apache but anything .net related would be passed through to the IIS server which would serve it back through via apache. Trouble is its been over a decade since using that so no idea how now.. hit google if it sounds useful to you.

[#7]

when i say wouldn't be supported, what i really meants was it's not installed and not something that would be.
i may look at http_referrer or similar so that if someone loads that page directly then it bounces them back to the login page, but that's for another day.

[#8]

Adding a second webserver is overkill, I think. I think the main point is whether IIS has mechanisms for internal redirection which obviate the need to send a URL back to the client for a further request, which is inefficient and prone to abuse in a way an internal server-side approach wouldn't be. Failing that, I'd expect your ASP script to handle it internally rather than sending a redirection to the client. After all, once the server receives the query string it must then do something similar anyway, so why bounce that information off the client at all, when the server already has it?