Richard White
|
| Posted: 07/23/2003, 2:50 PM |
|
I'm going through the CCS Quick Start Tutorials, and also the other day
looked at the Application Builder feature.
There is an "Authentication" feature in the application builder which seems
to want each database, indeed each application on a database, to *need*
user defined enrolment files for end users to be able to log into and use
the generated application. (Assuming that Authentication is used at all
that is).
QUESTIONS
1. Why can I not simply use the MySQL (or other) user accounts?
(ie. Why do I have to create yet another set of user ids/pwds?)
2. How could I use the MySQL user accounts for authentication?
(It's what I do on any other platform!)
3. How would I allow public to run (execute) certain PHP scripts to read
certain files, while denying access to the rest?
- via MySQL security?
- via some CCS security?
- via the web server directory/file security
(I seem to be getting user accounts in triplicate!!!!)
4. Is there a "this is how to implement user security" type
document from CCS which explains all this from basics up?
Many thanks (in advance)
|
|
|
 |
DonB
|
| Posted: 07/23/2003, 3:29 PM |
|
CCS security can be summed pretty simply: A logged-in user has three
Session variables defined - GroupID (denoting the level of access they are
granted), UserID (the user's unique identifier) and UserLogin (the user's
"name"). Note that these are the default variable names, you have the
ability to make them anything you want.
The implementation of security features, and the usage of these Session
variables is quite pervasive - they get utilized in a number of ways and
places throughout the application.
It is critical that these values are maintained server-side as session
variables, so they are secure from inquisitive users' prying eyes. You can
establish a user as "logged in" by generating these variables however you
like, although I'm sure Yes Software would officially recommend you stick
with the standard Login function or form. I don't know how MySQL stores
user identities, but if it is a table, then all you need to do is use the
same table for CCS as with other applications and there should be no
problem.
By default, each project WILL try to utilize a separate
database/table/security context, but it would be trivial to merge that into
a single source of authentication. As I said, it all comes down to the
three Session variables being defined.
DonB
"Richard White" <whiter@gmx.co.uk> wrote in message
news:bfn002$d6b$1@news.codecharge.com...
> I'm going through the CCS Quick Start Tutorials, and also the other day
> looked at the Application Builder feature.
>
> There is an "Authentication" feature in the application builder which
seems
> to want each database, indeed each application on a database, to *need*
> user defined enrolment files for end users to be able to log into and use
> the generated application. (Assuming that Authentication is used at all
> that is).
>
> QUESTIONS
>
> 1. Why can I not simply use the MySQL (or other) user accounts?
> (ie. Why do I have to create yet another set of user ids/pwds?)
>
> 2. How could I use the MySQL user accounts for authentication?
> (It's what I do on any other platform!)
>
> 3. How would I allow public to run (execute) certain PHP scripts to read
> certain files, while denying access to the rest?
> - via MySQL security?
> - via some CCS security?
> - via the web server directory/file security
> (I seem to be getting user accounts in triplicate!!!!)
>
> 4. Is there a "this is how to implement user security" type
> document from CCS which explains all this from basics up?
>
> Many thanks (in advance)
>
>
>
|
|
|
|
Richard White
|
| Posted: 07/23/2003, 3:56 PM |
|
"DonB" <7432D63DBB01D03A196B1EDD80E8@comcast.net> wrote in message
news:bfn287$flf$1@news.codecharge.com...
Thanks for the answer .... but;
> CCS security can be summed pretty simply: A logged-in user has three
> Session variables defined - GroupID (denoting the level of access they are
> granted), UserID (the user's unique identifier) and UserLogin (the user's
> "name"). Note that these are the default variable names, you have the
> ability to make them anything you want.
So in other words, I need to create a set of tables to hold user and group
definitions? If so, what's the specification for this? What I don't
understand is the envronment/implementation of this CCS security system, and
importantly how it relates to the user/security that exists in any SQL
database (eg. MySQL).
> The implementation of security features, and the usage of these Session
> variables is quite pervasive - they get utilized in a number of ways and
> places throughout the application.
Which is why I'm looking for a document that explains it for a newbie
developer (newbie to CCS/PHP, experienced in SQL/programming/security etc.)
>
> It is critical that these values are maintained server-side as session
> variables, so they are secure from inquisitive users' prying eyes. You
can
> establish a user as "logged in" by generating these variables however you
> like, although I'm sure Yes Software would officially recommend you stick
> with the standard Login function or form.
OK. So if I have a database, and I'm starting to develop an application for
it - where/how does this security system, and "standard Login function" get
added/generated etc.
> I don't know how MySQL stores
> user identities, but if it is a table, then all you need to do is use the
> same table for CCS as with other applications and there should be no
> problem.
MySQL stores this in a predefined database usually named "mysql".
> By default, each project WILL try to utilize a separate
> database/table/security context, but it would be trivial to merge that
into
> a single source of authentication. As I said, it all comes down to the
> three Session variables being defined.
Trivial once I've learned how to use CCS - but so far thanks to CCS bugs I
can't even get through the first main tutorial (I'm not counting the Hello
World one).
I can see there's a lot to learn with CCS. But if I can't progress through
the tutorials, then I may be back to square one, looking for another code
generator.
|
|
|
|
muhd fauzi
|
| Posted: 07/23/2003, 6:17 PM |
|
COMEON dont give up.
I once like you, struggling with cc then ccs ( especially ), but after
geeting thru the tutorial, then everything seems to fall in place. Start
with no user authentication first, then after familiar with ccs framework,
start playing with security. CCS security is suffice to cover 90% of the
application requirements. Unless you need to develop specific functionality,
the you need to customize the security framework.
thanks
"Richard White" <whiter@gmx.co.uk> wrote in message
news:bfn3qs$hma$1@news.codecharge.com...
>
> "DonB" <7432D63DBB01D03A196B1EDD80E8@comcast.net> wrote in message
>news:bfn287$flf$1@news.codecharge.com...
>
> Thanks for the answer .... but;
>
> > CCS security can be summed pretty simply: A logged-in user has three
> > Session variables defined - GroupID (denoting the level of access they
are
> > granted), UserID (the user's unique identifier) and UserLogin (the
user's
> > "name"). Note that these are the default variable names, you have the
> > ability to make them anything you want.
>
> So in other words, I need to create a set of tables to hold user and group
> definitions? If so, what's the specification for this? What I don't
> understand is the envronment/implementation of this CCS security system,
and
> importantly how it relates to the user/security that exists in any SQL
> database (eg. MySQL).
>
> > The implementation of security features, and the usage of these Session
> > variables is quite pervasive - they get utilized in a number of ways and
> > places throughout the application.
>
> Which is why I'm looking for a document that explains it for a newbie
> developer (newbie to CCS/PHP, experienced in SQL/programming/security
etc.)
>
> >
> > It is critical that these values are maintained server-side as session
> > variables, so they are secure from inquisitive users' prying eyes. You
> can
> > establish a user as "logged in" by generating these variables however
you
> > like, although I'm sure Yes Software would officially recommend you
stick
> > with the standard Login function or form.
>
> OK. So if I have a database, and I'm starting to develop an application
for
> it - where/how does this security system, and "standard Login function"
get
> added/generated etc.
>
> > I don't know how MySQL stores
> > user identities, but if it is a table, then all you need to do is use
the
> > same table for CCS as with other applications and there should be no
> > problem.
>
> MySQL stores this in a predefined database usually named "mysql".
>
> > By default, each project WILL try to utilize a separate
> > database/table/security context, but it would be trivial to merge that
> into
> > a single source of authentication. As I said, it all comes down to the
> > three Session variables being defined.
>
> Trivial once I've learned how to use CCS - but so far thanks to CCS bugs I
> can't even get through the first main tutorial (I'm not counting the Hello
> World one).
>
> I can see there's a lot to learn with CCS. But if I can't progress
through
> the tutorials, then I may be back to square one, looking for another code
> generator.
>
>
>
>
>
>
|
|
|
|
DonB
|
| Posted: 07/23/2003, 7:14 PM |
|
Look at the menu: Project Settings Security. You need only tell CCS a table
(or could be a view), a connection to the database where that table is
found, and the UserID, UserLogin, Password and GroupID (all picked from
dropdown lists). The "Advanced" button there let's you change the Session
variable names if you want to. Presumably you can map these data elements
to something in a table in the mysql database, but I'm not all that familiar
with MySQL.
Alternatively, by calling the function CCloginUser(), passing it a username
and password, you can login a user with your own code. To repeat, all this
does is generate some session variables.
The security is based on a table lookup, not an actual database or "server
login". You would probably find the table lookup most convenient -
especially if you implement any sort of "sign up" page. You don't really
want people creating logins to your server automatically.
If you really want a server login, then you'd be better off implementing a
login page that everyone has to hit before they can get to the CCS pages.
Do become familiar with what is in the "Common" files, in particular
Common.php or Common.asp. These contain the functions CCS provides to
simplify many common tasks.
DonB
|
|
|
|
|
