Enum
asked on
C++ and XML
I have a Web-based login page that uses a C++ dll to take a user to another web page. BUT there are different users that require to use the different web sites. Any one with any ideas?
ASKER
Thanks for the quick response! The web pages are writen with XML but it is not this that i am worried about.
I am struggling with the c++ dll that would connect the web sites together.
Dom
I am struggling with the c++ dll that would connect the web sites together.
Dom
That DLL is part of a CGI processing? Is it a DLL that is called by the web server to provide the web pages?
Could you explain more clearly what exactly is your situation and what exactly is your problem?
Alf
Could you explain more clearly what exactly is your situation and what exactly is your problem?
Alf
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
Answered by: Salte
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
Tinchos
EE Cleanup Volunteer
I will leave a recommendation in the Cleanup topic area that this question is:
Answered by: Salte
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
Tinchos
EE Cleanup Volunteer
1. You don't need to preserve context between the web pages.
2. You do need to preserve context one way or the other.
In the first case you have no problem. Each user access the page and that's it. However, as you have different users who want to access different web sites that is most likely not your situation, which brings us to the second case.
In the second case you need to preserve context.
In the simplest case you can simply let that context be in the URL. This means that you cannot have your web page stored on disk and simply show it. You must generate your web page on the fly.
If you have a web page written something like this:
----- file.html (or file.xml) -------
<html>
<head>
.....blah blah blah....
</head>
<body>
.....blah blah blah.....
<a href="http://www.foo.com/bar/baz.html">to user</a>
.....blah blah blah...
</body>
</html>
--------- end of file file.html (or file.xml) ------
Of course, in the case of xml the details will be slightly different etc etc but the main idea that concerns us is the same:
There's a tag here written as <a href="..."> This is the tag that takes you to a new web page. The point is that for different users you want them to go to different pages so then you have to generate a different text in that tag for the different users.
This is best done using some kind of html template file (for example in xml) which generate the file and can generate different URL's depending on context - i.e. the user etc.
So how do you get context?
There are several ways, the simplest is to simply put the context in the URL:
http://www.foo.com/bar.cgi?baz=gazonk
is a valid URL. It also have a variable defined named "baz" which has the value "gazonk". When processing this web page in the cgi script (or whatever you're using) you have the variable "baz" availalbe and can query what value it has. For example you could have an URL like this:
http://www.foo.com/bar.cgi?user=someone
then you can query the value of the variable "user" and then generate a web page depending on that value in some way, if the user is "someone" you generate one web page and if user is "someone-else" then you generate another web page.
One problem with this scheme is obviously that if you want to user to login it is a very bad idea to provide the password as a parameter this way and it is absolutely a no-no to provide 'user=someone' meaning that the user has already logged in as 'someone'. If you use password protection the username should NOT be passed over this way. So this brings you to the other ways to pass context.
There are essentially two ways to do it without putting the context in the URL.
1. Make a cookie and use the cookie for the session. A "cookie" is a bunch of data that your script store on the user's disk in a file there. This file is available to all the scripts that belong to the same 'session' and is per user per session. Typically your 'welcome' page opens a session and create a cookie and then the other pages can read the value of the coookie and modify it. The 'shopping cart' you see many online stores has uses this method and when you put something into the 'shopping cart' they update the cookie for the user and when you come to the final page to perform the purchase the cookie is read and the page generates a bill/receipt based on the info in the cookie.
The other method is to pass info using POST. This is what web pages like the EE site uses. When I type this very message here, I type it into an edit box on this web page. When I then press 'submit' I send a POST message. HTTP is actually a protocol that is very similar to sending E-mail. MIME was a format defined for mail which is also used by HTTP. The result is that every time you send a request to a HTTP server you essentially send it an E-mail. THe response you get back is also an E-mail - or at least in the same format as E-mails. Normally the requests doesn't have much text and is a simple GET request with no body to speak of. But a POST request has a body and can some times be a big body - big enough to hold the message I type in right now.
So this is the other way you can keep context. Generate a POST request and send over your info in the body of the POST message.
To send a POST request you use a <form> ...</form> tag. Inside that form there's usually some kind of button so that when that button is pressed the POST message is sent. There's also often an edit box where user can type the message to include in the message body.
However, in your case you might want to simply use it for holding your context and so choose to not have any edit box at all. Just build up your POST message based on 'fixed' data. The data is fixed in the web page you display but since that web page is in itself dynamically created on the fly that 'fixed' data is most likely not fixed at all but is also dynamic and contain the context you want to preserve. However, the data is fixed in the sense that the user who watches your web page cannot modify these data. If you want him to be able to modify or add more data than you send in the context simply add an edit box or some other form input item that includes the additional info.
Alf