I'm using AREV 2.03 and I'm trying to write a subroutine to encrypt passwords.

Example:

SUBROUTINE ENCRPT_PASS(PASSWORD)

I'm using a modified AREV.COMMON with the line COMMON W(100)

$INSERT UTILITY.PROGS, AREV.MODIFIED.COMMON

@ANS=PASSWORD; Unencrypted password… Then I set @ANS to my unencrypted password. CALL CATALYST('L', 'SEC,6') PASSWORD=@ANS; CALL CATALYST('L', 'SEC,7') @RECORD=PASSWORD At this point PASSWORD should be encrpyted??

RETURN

But when I run this subroutine (called from another program, not a template), I get the B720 Attempt to use COMMON variable when COMMON has not been defined.

What now?

Charles,

Try this $sec_encode function which works the same algorithm as $SEC does for encrypting passwords, at least in AREV 3.12.

DECLARE FUNCTION SEC_ENCODE

encrypted_password=SEC_ENCODE(entered_password)

The usual technique is to compare stored and entered encrypted strings. This is a one-way algorithm - there is no simple decryption technique - except by brute force. For fun you might want to re-read Eric Emu's column in SENL: http://www.sprezzatura.com/senl/senl16.htm

SEC references the Windows common - awkward outside an AREV window.

Thanks Steve, it works great.

In the future I'll just post all my programming requirements and just sit back while you do all the work!

Who knew programming could be so easy?

You seem to be using the 3.0 SEC rather than the earlier one - have you checked http://www.sprezzatura.com/revmedia/v1i6a7.htm?

The Sprezzatura Group

World Leaders in all things RevSoft

Every program that uses the common should be recompiled.

HEY THERE! We're on Arev 3.12 but WE don't have any SEC_ENCODE function. Where did THAT come from??? Why don't we have it???

Wayne

$SEC_ENCODE is not a routine supplied with AREV 3.12.

It's just a work-alike routine I purpose-built for Charles in this case.

Steve

I have not been able to get this to work in arev 3.12. When I look at $SEC it contains char(7):SYSPROG, but does not contain the trailing char(0). I have tried every combination of spaces, char(0) and the leading char value I can think of.

Can anyone shed any light on this?

From memory there was no suggestion that there would be trailing \00\ rather that if you chose to use a shorter name you'd have to truncate it with \00\. We'd prefer not to discuss object code mods in a public forum. If this info isn't enough then please feel free to contact us off line.

The Sprezzatura Group

World leaders in all things RevSoft

Thanks for the response.

I was able to solve the problem using a different approach. See the thread entitled "Make Secure Process." This approach works only if you know the password to sysprog, so it does not pose much of a security threat from unauthorized users.

As for discussing this in a public forum, I was just responding to the entry prior to mine, which contained the information about char(0). It has been public for a few years.

isn't modification of object code a violation of copyright and or licensing?

I would think this would be something for Revsoft to handle

Interesting question. The license says

Restrictions

You may not alter, merge, modify or adapt the software in any way including disassembling or decompiling. You may not loan, rent, or lease the software or any copy.

but then doesn't define "the software". So if we define the software as being that which ships in the box then making a copy of $SEC and modofying that would seem to be allowed. If we broaden the definition then heaven help you if you use an ASP model for your software ;).

way cool ..

One can only assume, then, that altering the software as it shipped out of the box (ie, creating applications) is a violation of the license? Unless one could determine how to do so without modifying or adapting the development files in some way?

Or conversely, perhaps you can change anything you want other than oengine.dll (where the serial number resides).

Definitely replacing SEC with your own version would be allowed (if not adviseable), if you are allowed to create any applications at all, since the inheritance/local replacement model is built in. Disassembling the existing code would not be (although doing so for your own amusement is not likely to be prosecuted).

Most of these licenses are written such that you could not use the software at all, if it was to be taken literally. That way, the attorneys who drew it up can reap additional income arguing over what is meant (along with your attorneys drawing the same income) until some judge who can barely spell email decides on the meaning "software", then starts to look at what is the meaning of modify or alter … until you (and perhaps the company) go broke or settle.

I don't think Arev uses oengine.dll.

View this thread on the forum...