Jump to content


- - - - -

Secuity question


19 replies to this topic

#1 Guest_Alan McKenna_*

Guest_Alan McKenna_*
  • Guests

Posted 18 February 2003 - 08:48 AM

Hi all,

I'm trying to create some new security functionality to provide rules such as password minimum lenght, pasword invalid chars, pasword expiry etc.

I think that the files that I need access to are logonf and security, but I only seem to have the filedef for security.

If I'm to write a screen to ask users to enter a new pasword I'm guessing that I'll need to update logonf somehow. Anyone have any ideas or suggestions as to how I could do this or how I could get my hands on the logonf filedef

Thanks,

Al

#2 Stuart Burton

Stuart Burton

    Advanced

  • Members
  • PipPipPip
  • 71 posts
  • Gender:Male
  • Location:Luton, United Kingdom

Posted 18 February 2003 - 01:10 PM

Not really sure that amending logonf is such a good idea...

#3 karoon

karoon

    Newbie

  • Members
  • Pip
  • 2 posts
  • Gender:Male

Posted 19 February 2003 - 04:17 AM

The attach file is the layout of LOGONF , you can create it by use file definitions screen but ensure DON'T PUT 'Physically create' flag to 'Y', for FILEDEF I don't have the layout

Attached Files



#4 Guest_Alan McKenna_*

Guest_Alan McKenna_*
  • Guests

Posted 19 February 2003 - 10:53 AM

Cheers, thanks for that!

#5 Guest_Neil Mellis_*

Guest_Neil Mellis_*
  • Guests

Posted 21 February 2003 - 01:47 PM

Do you realise that you are in breach of non-disclosure agreements with PROIV by publishing this file definition within a public forum.

PROIV reserve the right to change any internal file definition without consent, which may result in the failure of any application reliant on the definition.

Any customers requiring access to internal definitions should do so through their account managers or product suppliers.

This helps PROIV keep a track published material and the possible impact/notification of any future changes.

#6 Dan Shannon

Dan Shannon

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 374 posts
  • Gender:Male
  • Location:Australia

Posted 21 February 2003 - 02:01 PM

Neil

I've mentioned this before, but PRO-IV's standard NDA (the last 2 that I've seen at least) contains a double negative at a critical point - in effect it INSISTS that parties to the NDA must give away the information included in the bootstraps (it says you must not not do so). Which is nice... certainly makes the NDA easier to sign!

I still say PRO-IV should just publish the bootstrap file defs with each version anyway - everyone who develops uses them, you wouldn't need to 'track published material and the possible impact ... of future changes' - just publish the changes when you make them and us poor developers will have to cope.

But seriously, make sure that your NDA's are up to scratch because they're not really watertight!

Cheers

Dan Shannon

#7 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 21 February 2003 - 04:53 PM

Indeed... I think that they should be made public along time ago.

Most people have them/know them now anyway.

It helps coders to know them.

It would have helped me save hours and hours of work if I had been given the VIP bootstraps so that we could do work automatically... but since ProIV will not give out VIP bootstraps I had to do things manually.

This is a stupid argument that has been goning on for years and ProIV should publish them.

If they change the bootstraps, then its up to the coder to make the relavent changes to cope with the new definitions.

Rob D.

#8 Glenn Meyers

Glenn Meyers

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 221 posts
  • Gender:Male
  • Location:St. Louis, MO, United States
  • Interests:I also raise African Gray Parrots and build hot rod automobiles.

Posted 21 February 2003 - 10:11 PM

This is one of the remenants of the 'We own you, so be QUIET!' mentality that has been inflicted upon the PROIV user community for oh so long.

Do you lot REALLY believe that those of us in the real world will continue to stand for that???? Your dying sales numbers tell me that they won't...when will YOU lot get that message?? I know that we may be moving off of ProIV entirely, which puts me outta a job AGAIN....

NO CLOSED SYSTEM EVER FLOURISHED WHEN IN COMPETITION WITH AN OPEN ONE!! Learn from history or be condemmed to repeat it!

I shall now step down off the soapbox..
Thank you for your kind attention.

#9 Guest_Neil Mellis_*

Guest_Neil Mellis_*
  • Guests

Posted 21 February 2003 - 10:28 PM

It is the intention to publish (also under NDA) the VIP straps in Q2 2003. The VIP team will be tasked with providing a data model and xref update routines in the same way that we have published the VIP stub routines. As I said above the main reason for the NDA is for us to be aware of who will be affected by changes. I can't remember a single development customer under support that has been
refused the native boots, it's just a courtesy to PROIV.

I will be changing the NDA text (which in my version reads
OK) to encompass the support implications of sites with VIP straps and processes derived from their release.

I wouldn't mind some ideas on this regarding tracking and protection when direct access is made to source. I don't realy wish to police every file and would prefer to be completely open but this could lead to support issues outside our control or responsibility...

#10 Dan Shannon

Dan Shannon

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 374 posts
  • Gender:Male
  • Location:Australia

Posted 22 February 2003 - 12:07 AM

Neil

Are the defs for objprop.pro available yet? We didn't get them with the 5.0 boots when we asked for them...

I confess that I still don't really understand your issue wrt 'tracking and protection'. If you just released all the bootstraps (anything with genuine code in) along with some documentation and a big warning saying 'DON'T CHANGE THESE' then -

1. Changing the data in these files by code or manually outside of PRO-IV's dev tools can't affect the kernel - it just changes software. If I write some code using another tool and it doesn't GEN, that's my problem. If it fails because of something not working as advertised in the kernel, then that's PRO-IV's problem. If I change the bootstraps to suit myself, then I'm an idiot, which is my problem. I've never heard anyone even suggest changing the bootstraps - we all know it would be ridiculous to do it (don't we?). So that shouldn't be a support issue.

2. Tracking's MUCH easier if EVERYONE has the same information - i.e. all of it. Make the bootstraps part of each dev release.

3. Protection? Are you worried about the IP in there or something? I don't think you'd even need an NDA - just make it all part of the dev licence and then we can't transfer to third parties anyway or we break the terms of the original licence.

The bootstraps are an integral part of the language - it's much less functional without them - can't generate code automatically - which is a powerful feature in any language.

Neil, if you can clarify your issues/worries over support, and protection, and tracking, then maybe the developer community can be of some help. After all, many of us work for, or have worked for, software organisations, and have had to deal with similar issues - perhaps we can help PRO-IV to help us?

Cheers

Dan Shannon

#11 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 22 February 2003 - 06:52 AM

Neil,

Unless your 'routines' will allow absolutly total access to every field that is needed for a function, then that will not be good enough.

And if it does allow all fields, then why not just give us the file defs!!!

Also... will the 'routines' be written at 'kernel level' or will they just be global functions, that will be slow and unable to cope with large systems with 1000's of functions and the posibility of bugs?

Please, just publish the vip/native bootstraps to everyone (without having to sign something). This will only 'promote' the language... not hurt it!!!

I'm sure that I am not the only one with this view.

I cant think of any language that tries to shield their users from the real source code.... after all.. we are the developers, if we break our applications, then its our fault and we will fix it.

Rob D.

#12 Guest_Neil Mellis_*

Guest_Neil Mellis_*
  • Guests

Posted 23 February 2003 - 10:52 PM

All vipstraps will be published, the routines will only be provided (as global functions) to update XREFS but you could always duplicate if you wish.

When you see the VIPstraps you will realise that they are not much different from the native boots.

Two reasons for this:-

We may in the future choose to gen directly from VIP and
not native or a combination of both and width to retain current compatibility.

The native definitions and data model are old and very unorganised in terms of normalisation, naming and redundancy removal. The current versions of VIP have inherited this poor model and patched functionality via the use of XREF physical files and memory files.

I would really like to move the source to a more modern, performant and resilient architecture in the future which would absolve me from the limitations of PRO-ISAM. I would also like to consider for example moving all object references to 32 character (function,file etc). Which would involve major changes to both source and kernel but why shoe horn that into the current shape.

I understand your personal requirement for full disclosure but you would also be the first to whinge if we make significant changes that affect your use. It is also my experience that the first port of call we developers screw up their source code tends to be PROIV support or this forum - not all developers are as competent with the bootstraps as you and I (and Dan, Chris Pepper Dick Basett etc.....)

Anyway I estimate about 2-3 months before I publish VIPStaps maybe sooner If you guys stop hassling me.

#13 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 23 February 2003 - 11:47 PM

I have coped for the last 13 years with changes to the bootstraps, without a 'whinge'.

I can see no need for changing the layout of the bootstrap files in the way you have, it will just create more places for errors to occur.

I have written (and will hopefully soon finish) a full ProIV function editor that runs of the original bootstaps. I have had no problem making it fast and smooth to edit a function using the existing structure... If I had to update all the files/xref files like VIP has to, then it would be much slower.

The only layout that has caused me some problems with performance is the 'new' objprop.pro since there are so many records in that file. One record for each property is not good.

The only other format that might be more 'standard' would be to store the bootstraps into a flat text ascii file, like most other lanuages.

Rob D.

#14 Guest_Neil Mellis_*

Guest_Neil Mellis_*
  • Guests

Posted 24 February 2003 - 08:34 AM

I rest my case !!

Because your editor or tools need a stationary architecture we have to limit the extent of change !!!

In your abstracted Visual Basic based editor how do you store the source (and I don't mean lines of logic). I would think is held as an object model with reference pointers.

How fast is it when you have to read the pro-isam source
records flatten out the data and send it in chunks client side and then repeat the process to build the function.

Where is the internalexternal linkage information for functions and internal object references etc you work that out on the fly? or walk the entire pro-isam source.


If you want an open developer community why then did you not either contribute to the design and trial of VIP or
create your editor as open source/design. Self-interest pervades!

#15 Dan Shannon

Dan Shannon

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 374 posts
  • Gender:Male
  • Location:Australia

Posted 24 February 2003 - 11:28 AM

No 3rd party editor that I've seen 'needs a stationary architecture' - but they do need access to the bootstraps to enable upgrades when new versions of PRO-IV arise.

I'd love to see an Open Source project to build a genuinely good PRO-IV editor. I know there are lots of developers out there who've written their own (of varying quality) and I'm sure we could collectively build some seriously good tools. Neil, would PRO-IV be in favour of such a thing? It would need some (but not a lot) active support (particularly in the form of bootstraps) from you guys to make it work really well.

I'd love to see PRO-IV compile source from a sensibly structured set of bootstraps. But I don't expect this is likely to happen, because re-building the kernel from the ground up for all the supported platforms, with the resources that PRO-IV have historically seemed to have for development, doesn't seem probable. My own opinion, for various reasons, is that historically PRO-IV's in-house-developed editors have not been all that good - this may be for all kinds of reasons, which I'm not really interested in anyway.

If we're serious about development tools, maybe this development community should set about creating some, hopefully (though not necessarily) with PRO-IV's blessing. I'd certainly be willing to contribute the editor that I've written over the last 10 years (and that I'm sure I'll never make any money out of directly).

I'll put up a poll to gauge some reaction. Rob, you might want to give some thought to this as well?

Cheers

Dan Shannon



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users