Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 09 NOV 2000 03:28:40PM Jackie Jones wrote:

Help with Web Security

This is to ask if our logic is correct, and what, if anything,

to do with the Inet_Security function.

When the user logs into the order entry site on our web application,

we ask for the customer code and authorization code, then what

they want to do - enter a new order, check existing orders, etc.

We check the customer code against an OI file to check the

associated password. If its not there or is incorrect, we

show an Html screen with the message - please reenter your authorization code.

The login screen is the entry point for the other screens,

so all input and processing goes through this screen.

If they want to enter a new order, the data comes in from Inet_Queryparam

through this first login screen then calls a stored procedure

with the customer code and authorization code and data,

and builds and returns the other screens. For example,

depending on the customer code, the order entry screens show particular products they are authorized to buy, with their

pricing, and lists of their own shipto locations.

So since this is the entry point, it always checks

to make sure the customer code matches their password on file.

Is this enough? Could another user accidentally get this customer's

list of products and prices or lists of shiptos or their orders?

If this user interrupts the process and goes to another site and

then comes back, can this get mixed up?

What does the Inet_Security function do? How do you activate

it and use it?

Also, other web sites we've looked at seem to have a standardized

login screen like the one on this Revsoft Online discussion site.

If we could use that, then our user wouldn't have to enter their customer code and authorization code. What is this, and how can we use this?

Thank you for any help.


At 09 NOV 2000 04:00PM WinWin/Revelation Technical Support wrote:

Jackie-

INET_Security is the first program that any request for data must pass through. It is a function- it returns a null if everything is OK, or can return am HTML string indicating what the error was.

We've used it by itself, as well as in conjunction with server based security (such as Apache and the .htaccess file)

An example might be where you would want to see if the user has logged in to the web server. If they have not, you would redirect them to your login page.

Example:

Function Inet_Security(Request, Proc_name)

$Insert Inet_Equates

Declare Function Inet_Msg

remote_user=Request
if len(remote_user) then
  varHtml='
End Else
  varHtml=Inet_Msg(Request, 'Please Login [url=http://127.0.0.1/login.htm]here[/url]')
End

return VarHtml

Conceivable, you could check for nearly any sort of user validation- OI usernames, IP addresses, or whatever.

Hope it helps-

Mike Ruane


At 09 NOV 2000 04:12PM Donald Bakke wrote:

Jackie,

I'll offer a brief response that will hopefully clear the fog. The subject of security can be discussed in great detail but I don't think you need that.

INET_SECURITY is automatically called whenever an OICGI request is submitted to OpenInsight. It always preceeds your own INET routines. It's kind of like a Pre-Initialize process for an AREV window (or a CREATE event for an OI window.)

Until you add your own custom logic to INET_SECURITY it is simply a shell that allows processing to continue. You can open it up in the SYSPROG account to get an idea of how you would incorporate its use.

The dialog box method for allowing access to a website (or certain portions of a website) are a feature of the web server software. You could simulate this using HTML and JavaScript. The key difference, however, is that the former requires you to maintain a different set of security information in the web server's system where as the HTML and/or Javascript can use OICGI to get the information from an OI database.

Barring any logical flaws there should not be the possibility that user #1 would get access to the information for user #2. A previous version of the OICGI, however, did have a bug where if the engine was busy it would return the most recent page. Unfortunately it did this indiscriminately so if the last page served was for user #1 and user #2 triggered the problem then user #2 would get user #1's page! Just make sure you are using the OICGI from OI v3.7.2 or v3.7.3.

If you really want to add more tracibility to your site you could do a couple of more things:

1. Track the users IP address. This can be retrieved from the request string.

2. Once a user has successfully logged in. Make sure that any HTML returned to the user also embeds a hidden submit tag with the user's ID. This was you can always get their ID from the request string.

Hope this helps. Let us know if you need for information.

[email protected]

SRP Computer Solutions, Inc.


At 09 NOV 2000 05:30PM Jackie Jones wrote:

Thank you Donald and Mike.

I'm going to work with what you've both told me.

Thank you for telling me about the issue that was resolved.

Can you use Javascript to show a dialog box that

doesn't take up the entire screen?

Thank you very much for your help.

And George says Congratulations, Mike.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/0d8ba77c09c854e58525699200707cee.txt
  • Last modified: 2024/01/04 21:00
  • by 127.0.0.1