Stopping double clicking of a file

  • Hi,
    I need to turn off the ability to allow users to double click on a
    file and have them open it up. There are security reasons for this,
    as we do not want to allow students to open up the file and change
    grades or attendance. So we have to go through our login procedure
    that allows the teachers or administrators to open the file. But I
    can not see anyway to turn this off. I know in Carbon this is done
    through Apple Events, and ma sure that it is done the same way with
    Cocoa.  I have looked on Apples site and searched this list, but have
    not be able to find the answer to this.

    Thanks in advance for any help.
  • Maybe I'm missing something, but this seems a strange way to go about
    it. Why don't you just use file permissions to deny certain users
    access to a file? I would imagine that permissions for users, groups,
    and others offer enough flexibility to solve this without trying to
    modify the user interface at such a basic level.

    Hank Heijink
    www.hankheijink.com
    <hankh...>

    On Oct 4, 2006, at 2:07 PM, development2 wrote:

    > Hi,
    > I need to turn off the ability to allow users to double click on a
    > file and have them open it up. There are security reasons for this,
    > as we do not want to allow students to open up the file and change
    > grades or attendance. So we have to go through our login procedure
    > that allows the teachers or administrators to open the file. But I
    > can not see anyway to turn this off. I know in Carbon this is done
    > through Apple Events, and ma sure that it is done the same way with
    > Cocoa.  I have looked on Apples site and searched this list, but
    > have not be able to find the answer to this.
    >
    > Thanks in advance for any help.
    >
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<hankh...>
    >
    > This email sent to <hankh...>
    >
  • Sorry can't do that. These files are all stored on Windows servers,
    and they need to be able to create new files, delete files, etc.

    I have to disallow the file form double clicking. It can be caught,
    at least in carbon I have done that in the past.

    Thanks,

    On Oct 4, 2006, at 12:19 PM, Hank Heijink wrote:

    > Maybe I'm missing something, but this seems a strange way to go
    > about it. Why don't you just use file permissions to deny certain
    > users access to a file? I would imagine that permissions for users,
    > groups, and others offer enough flexibility to solve this without
    > trying to modify the user interface at such a basic level.
    >
    > Hank Heijink
    > www.hankheijink.com
    > <hankh...>
    >
    > On Oct 4, 2006, at 2:07 PM, development2 wrote:
    >
    >> Hi,
    >> I need to turn off the ability to allow users to double click on a
    >> file and have them open it up. There are security reasons for
    >> this, as we do not want to allow students to open up the file and
    >> change grades or attendance. So we have to go through our login
    >> procedure that allows the teachers or administrators to open the
    >> file. But I can not see anyway to turn this off. I know in Carbon
    >> this is done through Apple Events, and ma sure that it is done the
    >> same way with Cocoa.  I have looked on Apples site and searched
    >> this list, but have not be able to find the answer to this.
    >>
    >> Thanks in advance for any help.
    >>
    >>
    >> _______________________________________________
    >> Do not post admin requests to the list. They will be ignored.
    >> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >> Help/Unsubscribe/Update your Subscription:
    >> http://lists.apple.com/mailman/options/cocoa-dev/<hankh...>
    >>
    >> This email sent to <hankh...>
    >>
    >
    >
  • Regardless of being able to keep from double-clicking via Carbon,
    how do you account for an AppleScript opening the file. How about the
    command line "open /Path/To/File.ext"? What about someone using a
    text editor (or an editor of their choice) that can open any file via
    "File|Open" or by dragging the file onto the app's icon? I'm sure
    there are plenty of other ways to open a file. You *won't* secure
    your data this way.

      If your issue is privileges (ie, you don't want certain people
    opening the file), you most definitely are going about this the wrong
    way and this can definitely be handled by properly configuring your
    file permissions on the server in question. You will need to go back
    to basics and learn how to properly make use of user/file permissions
    to solve this problem correctly.

    --
    I.S.

    On Oct 4, 2006, at 2:24 PM, development2 wrote:

    > Sorry can't do that. These files are all stored on Windows servers,
    > and they need to be able to create new files, delete files, etc.
    >
    > I have to disallow the file form double clicking. It can be caught,
    > at least in carbon I have done that in the past.
    >
    > Thanks,
    >
    > On Oct 4, 2006, at 12:19 PM, Hank Heijink wrote:
    >
    >> Maybe I'm missing something, but this seems a strange way to go
    >> about it. Why don't you just use file permissions to deny certain
    >> users access to a file? I would imagine that permissions for
    >> users, groups, and others offer enough flexibility to solve this
    >> without trying to modify the user interface at such a basic level.
    >>
    >> Hank Heijink
    >> www.hankheijink.com
    >> <hankh...>
    >>
    >> On Oct 4, 2006, at 2:07 PM, development2 wrote:
    >>
    >>> Hi,
    >>> I need to turn off the ability to allow users to double click on
    >>> a file and have them open it up. There are security reasons for
    >>> this, as we do not want to allow students to open up the file and
    >>> change grades or attendance. So we have to go through our login
    >>> procedure that allows the teachers or administrators to open the
    >>> file. But I can not see anyway to turn this off. I know in Carbon
    >>> this is done through Apple Events, and ma sure that it is done
    >>> the same way with Cocoa.  I have looked on Apples site and
    >>> searched this list, but have not be able to find the answer to this.
    >>>
    >>> Thanks in advance for any help.
    >>>
    >>>
    >>> _______________________________________________
    >>> Do not post admin requests to the list. They will be ignored.
    >>> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >>> Help/Unsubscribe/Update your Subscription:
    >>> http://lists.apple.com/mailman/options/cocoa-dev/<hankh...>
    >>>
    >>> This email sent to <hankh...>
    >>>
    >>
    >>
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/idiotsavant2005%
    > 40gmail.com
    >
    > This email sent to <idiotsavant2005...>
  • On 04 Oct 06, at 11:24, development2 wrote:
    > On Oct 4, 2006, at 12:19 PM, Hank Heijink wrote:
    >> On Oct 4, 2006, at 2:07 PM, development2 wrote:
    >>> Hi,
    >>> I need to turn off the ability to allow users to double click on
    >>> a file and have them open it up. There are security reasons for
    >>> this, as we do not want to allow students to open up the file and
    >>> change grades or attendance. So we have to go through our login
    >>> procedure that allows the teachers or administrators to open the
    >>> file. But I can not see anyway to turn this off. I know in Carbon
    >>> this is done through Apple Events, and ma sure that it is done
    >>> the same way with Cocoa.  I have looked on Apples site and
    >>> searched this list, but have not be able to find the answer to this.
    >>>
    >>> Thanks in advance for any help.
    >>
    >> Maybe I'm missing something, but this seems a strange way to go
    >> about it. Why don't you just use file permissions to deny certain
    >> users access to a file? I would imagine that permissions for
    >> users, groups, and others offer enough flexibility to solve this
    >> without trying to modify the user interface at such a basic level.
    >
    > Sorry can't do that. These files are all stored on Windows servers,
    > and they need to be able to create new files, delete files, etc.
    >
    > I have to disallow the file form double clicking. It can be caught,
    > at least in carbon I have done that in the past.

    That's not possible, as the event created by double-clicking the file
    is handled within the Finder, which you shouldn't be trying to patch.
    More importantly, there are many other ways to open the file,
    including but not limited to:

    * Pressing Cmd-O in the Finder

    * Pressing Cmd-down arrow in the Finder

    * Right-clicking on the file in the Finder and selecting Open from
    the menu

    * Dragging the file onto an application icon (in the Finder or on the
    Dock)

    * Opening the application which reads the file and opening it from
    within there

    * Running /usr/bin/open from a terminal

    * Copying the file to the desktop, renaming it to a .txt, and opening
    that

    * Copying the file to a removable drive and examining it on another
    machine

    Store the file on a password-protected share on the Windows server.
    Don't try to implement file protections on the client - THAT WILL NOT
    WORK.
  • Am 04.10.2006 um 20:24 schrieb development2:

    > Sorry can't do that. These files are all stored on Windows servers,
    > and they need to be able to create new files, delete files, etc.

    What is the problem?

    Just store the files the users should not change in a different
    directory with different permissions.

    > I have to disallow the file form double clicking. It can be caught,
    > at least in carbon I have done that in the past.

    Double-clicking is just *one* way to open a file.

    You can also - for example - drag the file to an application icon.

    Or you can use the terminal - remember: this is a unix operating system.

    I don't know if that what you want (disallow double clicking) is
    possible. But even if it were, it would not solve your problem in any
    way, because there would be so much other ways to open/change the file.

    You *have* to work with users/groups/permissions. This is the only
    way to do it.

    klg

    PS: that reminds me of a story I've read some months ago.

    An US agency has released a document where some parts of the text
    should not be readeable - because of security concerns. They just set
    Foreground-Color to black and Background-Color to black on these parts.
    Of course, in Word and even in Acrobat, these parts of the text where
    not readable.
    But in the PDF (opened with a text-editor, for example) all the
    information that was black-on-black was readable for everyone ...
  • Well never mind I thought Apple might make this kind of easy to
    override. But I will have to do something different in the app to fix
    this properly.

    thanks.

    On Oct 4, 2006, at 12:46 PM, I. Savant wrote:

    >
    > Regardless of being able to keep from double-clicking via Carbon,
    > how do you account for an AppleScript opening the file. How about
    > the command line "open /Path/To/File.ext"? What about someone using
    > a text editor (or an editor of their choice) that can open any file
    > via "File|Open" or by dragging the file onto the app's icon? I'm
    > sure there are plenty of other ways to open a file. You *won't*
    > secure your data this way.
    >
    > If your issue is privileges (ie, you don't want certain people
    > opening the file), you most definitely are going about this the
    > wrong way and this can definitely be handled by properly
    > configuring your file permissions on the server in question. You
    > will need to go back to basics and learn how to properly make use
    > of user/file permissions to solve this problem correctly.
    >
    > --
    > I.S.
    >
    >
    > On Oct 4, 2006, at 2:24 PM, development2 wrote:
    >
    >> Sorry can't do that. These files are all stored on Windows
    >> servers, and they need to be able to create new files, delete
    >> files, etc.
    >>
    >> I have to disallow the file form double clicking. It can be
    >> caught, at least in carbon I have done that in the past.
    >>
    >> Thanks,
    >>
    >> On Oct 4, 2006, at 12:19 PM, Hank Heijink wrote:
    >>
    >>> Maybe I'm missing something, but this seems a strange way to go
    >>> about it. Why don't you just use file permissions to deny certain
    >>> users access to a file? I would imagine that permissions for
    >>> users, groups, and others offer enough flexibility to solve this
    >>> without trying to modify the user interface at such a basic level.
    >>>
    >>> Hank Heijink
    >>> www.hankheijink.com
    >>> <hankh...>
    >>>
    >>> On Oct 4, 2006, at 2:07 PM, development2 wrote:
    >>>
    >>>> Hi,
    >>>> I need to turn off the ability to allow users to double click on
    >>>> a file and have them open it up. There are security reasons for
    >>>> this, as we do not want to allow students to open up the file
    >>>> and change grades or attendance. So we have to go through our
    >>>> login procedure that allows the teachers or administrators to
    >>>> open the file. But I can not see anyway to turn this off. I know
    >>>> in Carbon this is done through Apple Events, and ma sure that it
    >>>> is done the same way with Cocoa.  I have looked on Apples site
    >>>> and searched this list, but have not be able to find the answer
    >>>> to this.
    >>>>
    >>>> Thanks in advance for any help.
    >>>>
    >>>>
    >>>> _______________________________________________
    >>>> Do not post admin requests to the list. They will be ignored.
    >>>> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >>>> Help/Unsubscribe/Update your Subscription:
    >>>> http://lists.apple.com/mailman/options/cocoa-dev/<hankh...>
    >>>>
    >>>> This email sent to <hankh...>
    >>>>
    >>>
    >>>
    >>
    >> _______________________________________________
    >> Do not post admin requests to the list. They will be ignored.
    >> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >> Help/Unsubscribe/Update your Subscription:
    >> http://lists.apple.com/mailman/options/cocoa-dev/idiotsavant2005%
    >> 40gmail.com
    >>
    >> This email sent to <idiotsavant2005...>
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/development2%
    > 40bitblasters.com
    >
    > This email sent to <development2...>
    >
  • On Oct 4, 2006, at 3:14 PM, development2 wrote:
    > Well never mind I thought Apple might make this kind of easy to
    > override. But I will have to do something different in the app to
    > fix this properly.
    >
    > thanks.

      Why would they? It wouldn't serve any purpose since this is not
    how security is handled on any operating system anywhere. :-)

      The way to fix this properly is to properly use the permissions
    system that is built into the operating system you're using.

    --
    I.S.
  • On Oct 4, 2006, at 15:14 , development2 wrote:

    > Well never mind I thought Apple might make this kind of easy to
    > override. But I will have to do something different in the app to
    > fix this properly.
    >
    > thanks.

    Why should you make changes in your app? SMB shares support
    permissions, just flip some bits on the server and you're done. Also,
    why is critical grade information stored even in the same share as
    the student-accessible directories?

    -M
  • Exactly what I need thank you so much. And sorry to everyone for all
    the chatter on the list.

    thanks.
    On Oct 4, 2006, at 1:23 PM, Eric Schlegel wrote:

    >
    > On Oct 4, 2006, at 11:43 AM, development2 wrote:
    >
    >> Or I guess what I could do, is some how trap it before it opens
    >> the file, and show the Login window, and wait until a valid login,
    >> then I could open it. But i guess that would be the same thing, I
    >> need to be able to know if the file is double clicked.
    >
    > I think what you need to do is provide an NSApplication delegate
    > that implements application:openFile:, and put up your login window
    > inside that method. See <http://developer.apple.com/documentation/
    > Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/
    > Reference/Reference.html#//apple_ref/occ/instm/NSObject/
    > application:openFile:>.
    >
    > -eric
    >
    >
  • Hi!

    Am 04.10.2006 um 21:14 schrieb development2:

    > Well never mind I thought Apple might make this kind of easy to
    > override.

    Even if Apple would have made this (double-click) easy to overrride,
    it would not help you.

    It is just that your approach is - no offense - terribly wrong.

    You have to work with users and permissions.

    If you don't do that, your solution will be only some kind of
    cosmetics, but not secure by any means.

    > But I will have to do something different in the app to fix this
    > properly.

    In what app? As far as I understood you want the user not to be able
    to double-click a file in the finder to open it?!?

    What app are you referring to?

    klg
  • Hi!

    Am 04.10.2006 um 21:25 schrieb development2:

    > first of all, I am not talking about permissions. I am talking
    > about opening a file from the TEACHERS computer, if the student
    > gets on there with out there permission and they are already logged
    > into the server, then what do you do, since they already have the
    > proper permissions for all of these file, because they are logged
    > on properly.

    Okay, that changes the situation a little bit.

    > The student can double click on the file and change there grades or
    > attendance or whatever and the teacher would not know.

    Yes, I see your point.

    But I also think your approach is wrong. Because students could
    easily learn how to open a file via the terminal or other means.

    My approach would be to store the information the students should not
    access in an encrypted file.

    Yojimbo is a good example how that could be achieved.

    You can download it and test it here:

    http://www.barebones.com/products/yojimbo/

    I've bought it because even if someone gets his/her hands on my
    computer while I'm away, my sensitive information is secure because
    it is stored encrypted (256-bit, secure enough for me ;-) ) and
    password-protected.

    Every time I access sensitive information (for example: passwords,
    sensitive data of projects I'm working on), I have to enter my
    Yojimbo password.

    That may sound inconvinient, but I think it is worth it.

    You could do it this way, too.

    Encrypt the data of the files you want to protect and have the
    teacher to enter the password every time he/she accesses the file.

    That approach would IMHO be far more secure than that what you had in
    mind.

    But - of course - your teachers have to be aware of security risks.
    If you leave a door that should be locked, open, then you have a
    problem ...

    > I am not worried about them accessing form a different computer,
    > because then that is a permission issue and that will all be set up
    > properly and the student will not even see it because they can't
    > get on the server.

    Okay.

    > And if you say this does not happen, I will give you some email
    > address of teachers throughout the country that have experienced this.

    Now that I know what you mean, I believe that. ;-)

    > I am trying to make sure that all class file access goes through
    > our sanctioned method of opening a file, that is all. If it does
    > everything works fine.

    As I said, your approach is wrong, IMHO.

    Of course, double-clicking is the most straight-forward thing to do.
    But there are other means to open a file.

    Another point: if students on a teacher's computer could not open a
    file by any means, the teacher would also not be able to do it. That
    is not what you want?

    Why not provide the teacher(s) with a password to access the
    restricted files?

    klg
  • I have to say simply popping up a login dialog when your application
    is asked to open a file type you support isn't likely to protect the
    data.

    Are your data files encrypted? If so how? Who holds the keys?

    What about someone simply deleting or replacing the data file with a
    copy from say some time in the past... etc?

    -Shawn

    On 10/4/06, development2 <development2...> wrote:
    > Exactly what I need thank you so much. And sorry to everyone for all
    > the chatter on the list.
    >
    > thanks.
    > On Oct 4, 2006, at 1:23 PM, Eric Schlegel wrote:
    >
    >>
    >> On Oct 4, 2006, at 11:43 AM, development2 wrote:
    >>
    >>> Or I guess what I could do, is some how trap it before it opens
    >>> the file, and show the Login window, and wait until a valid login,
    >>> then I could open it. But i guess that would be the same thing, I
    >>> need to be able to know if the file is double clicked.
    >>
    >> I think what you need to do is provide an NSApplication delegate
    >> that implements application:openFile:, and put up your login window
    >> inside that method. See <http://developer.apple.com/documentation/
    > > Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/
    >> Reference/Reference.html#//apple_ref/occ/instm/NSObject/
    >> application:openFile:>.
    >>
    >> -eric
    >>
    >>
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<shawnce...>
    >
    > This email sent to <shawnce...>
    >
  • Why wouldn't turning on the screensaver lock (for password) solve the
    problem? Alternatively, the application could detect the screensaver
    activation itself and expire its authorization- sshkeychain does this:
    http://www.sshkeychain.org/

    In any case, keeping append-only logs of activity for anything as
    important as grades is crucial. The OP's problem is not new.

    -M

    On Oct 4, 2006, at 15:54 , Shawn Erickson wrote:

    > I have to say simply popping up a login dialog when your application
    > is asked to open a file type you support isn't likely to protect the
    > data.
    >
    > Are your data files encrypted? If so how? Who holds the keys?
    >
    > What about someone simply deleting or replacing the data file with a
    > copy from say some time in the past... etc?
    >
    > -Shawn
  • Hi!

    Am 04.10.2006 um 21:47 schrieb development2:

    > Hi yourself,
    >
    > On Oct 4, 2006, at 1:29 PM, Klaus L. Greulich wrote:
    >
    >> Hi!
    >>
    >> Am 04.10.2006 um 21:14 schrieb development2:
    >>
    >>> Well never mind I thought Apple might make this kind of easy to
    >>> override.
    >>
    >> Even if Apple would have made this (double-click) easy to
    >> overrride, it would not help you.
    >
    > Well you may be right there, I just needed a way to trap it so the
    > user can not open the file, without
    > going through our sanctioned method.

    Well, now that I realize what you are talking about (took some
    time ;-) )

    I've also read the answer regarding the App delegate.

    But what if the students try to open the file with a text editor or
    vi or emacs or something like that?

    Don't underestimate the ressourcefulness of your enem ... ahh ...
    students.

    >
    >>
    >> It is just that your approach is - no offense - terribly wrong.
    >
    > Hey that is really nice, given that you know nothing of how our app
    > works.

    You have not provided much information about it. Or have I missed
    something?

    > But to make it clear the
    > approach that I have asked about IS the proper way to go about it.

    In my Humble Opinion, it is not.

    Because there are other ways (or maybe other ways) to edit you
    sensitive data than you application.

    And if I imagine some student who wants to change something ...

    >
    >>
    >> You have to work with users and permissions.
    >
    > Yeah permissions are already set up for users, but these students
    > can get on these teachers computers and they already have the
    > servers mounted and permissions set. So what do you do there, since
    > permissions are correct for that teacher?

    Use password protection and encyption.

    > You have to direct them through a method of opening these files, so
    > that they can be authorized to use the file. The only way to do
    > that is make them go through some sanctioned way of opening these
    > files. That is what I am trying to do. I don't have to worry about
    > permissions the server takes care of that for me. I just have to
    > worry about making sure that the person who looks at these files
    > has access set up in our server software.
    >
    >>
    >> If you don't do that, your solution will be only some kind of
    >> cosmetics, but not secure by any means.
    >
    > If opening of ALL files goes through my sanctioned way of opening
    > files, then security is already taken care of.
    >>
    >>> But I will have to do something different in the app to fix this
    >>> properly.
    >>
    >> In what app? As far as I understood you want the user not to be
    >> able to double-click a file in the finder to open it?!?
    >>
    >> What app are you referring to?
    >
    > Im my app!! did I mention any other one???

    In your original post you wrote:

    "I need to turn off the ability to allow users to double click on a
    file and have them open it up. There are security reasons for this,
    as we do not want to allow students to open up the file and change
    grades or attendance."

    You didn't write: "and have them open it up *in my application*"

    I thought you didn't want (for example) the students to open up a
    restricted Word or Excel file via the Finder.

    If it is your own application, securing sensitive information via
    encryption should be not a problem, see Yojimbo.

    klg
  • On Oct 4, 2006, at 4:11 PM, Klaus L. Greulich wrote:

    >>> It is just that your approach is - no offense - terribly wrong.
    >>
    >> Hey that is really nice, given that you know nothing of how our
    >> app works.
    >
    > You have not provided much information about it. Or have I missed
    > something?

      Meaning no offense, I think this is the crux of the problem. The
    OP has not posted enough information to give the best response, which
    is why everybody's asking so many questions. There's no need to be
    argumentative about it (the OP, not Klaus), but given the information
    provided so far, the approach is *most definitely* wrong for a number
    of reasons that have been well-illustrated. It's not an attack if
    someone tells you so (unless of course it's followed by a "you idiot"
    or something equally insulting).

      If you (the OP) disagree with the advice, that's fine, but if
    you're going to ask professionals for help, be prepared to hear
    "that's not the right way to go about it". Whether you take that
    advice is, of course, up to you.

      I suggest going with the route I and several others have mentioned
    - encrypt the contents of the data file, requiring a password to open
    it. Also note *well* the plain truth that there is *no* solution to
    users leaving this sensitive data unlocked and unattended - that has
    to be addressed with the users in question as a matter of policy and
    training.

    --
    I.S.
  • Hi!

    Am 04.10.2006 um 22:26 schrieb I. Savant:

    > Also note *well* the plain truth that there is *no* solution to
    > users leaving this sensitive data unlocked and unattended - that
    > has to be addressed with the users in question as a matter of
    > policy and training.

    I agree.

    But there may be some kind of help to secure the files.

    Just lock the file after some period of time - say: 10 minutes of not
    using the application - requiring the password to access the file again.

    Okay, the teacher could enter the password and leave the room just
    after that.

    But that will not be the normal case.

    Many applications do it that way (OS X for example, if you have a
    screensaver active requiring a password to deactivate or phpMyAdmin
    that asks you to login again after some period of time).

    klg
  • What's wrong with using samba permissions?

    Surely each user will have a username, just don't allow access to the
    file for any users but the teachers?

    Windows permissions aren't THAT lax!

    On 4 Oct 2006, at 9:44 pm, Klaus L. Greulich wrote:

    > Hi!
    >
    > Am 04.10.2006 um 22:26 schrieb I. Savant:
    >
    >> Also note *well* the plain truth that there is *no* solution to
    >> users leaving this sensitive data unlocked and unattended - that
    >> has to be addressed with the users in question as a matter of
    >> policy and training.
    >
    > I agree.
    >
    > But there may be some kind of help to secure the files.
    >
    > Just lock the file after some period of time - say: 10 minutes of
    > not using the application - requiring the password to access the
    > file again.
    >
    > Okay, the teacher could enter the password and leave the room just
    > after that.
    >
    > But that will not be the normal case.
    >
    > Many applications do it that way (OS X for example, if you have a
    > screensaver active requiring a password to deactivate or phpMyAdmin
    > that asks you to login again after some period of time).
    >
    > klg
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<cocoa...>
    >
    > This email sent to <cocoa...>
  • As mentioned previously in this thread, the OP is concerned with
    teachers leaving themselves logged in with the computer unattended.
    In this case, a student could easily manipulate any files the teacher
    has rights to.

    --
    I.S.

    On Oct 4, 2006, at 4:53 PM, Drarok Ithaqua wrote:

    > What's wrong with using samba permissions?
  • Again this is NOT a permissions issue. Permissions are set up
    correctly, i am trying to direct all opening of our files through a
    bottle neck, that I control. That is it.

    And I have found and answer that will work.

    On Oct 4, 2006, at 2:53 PM, Drarok Ithaqua wrote:

    > What's wrong with using samba permissions?
    >
    > Surely each user will have a username, just don't allow access to
    > the file for any users but the teachers?
    >
    > Windows permissions aren't THAT lax!
    >
    > On 4 Oct 2006, at 9:44 pm, Klaus L. Greulich wrote:
    >
    >> Hi!
    >>
    >> Am 04.10.2006 um 22:26 schrieb I. Savant:
    >>
    >>> Also note *well* the plain truth that there is *no* solution to
    >>> users leaving this sensitive data unlocked and unattended - that
    >>> has to be addressed with the users in question as a matter of
    >>> policy and training.
    >>
    >> I agree.
    >>
    >> But there may be some kind of help to secure the files.
    >>
    >> Just lock the file after some period of time - say: 10 minutes of
    >> not using the application - requiring the password to access the
    >> file again.
    >>
    >> Okay, the teacher could enter the password and leave the room just
    >> after that.
    >>
    >> But that will not be the normal case.
    >>
    >> Many applications do it that way (OS X for example, if you have a
    >> screensaver active requiring a password to deactivate or
    >> phpMyAdmin that asks you to login again after some period of time).
    >>
    >> klg
    >> _______________________________________________
    >> Do not post admin requests to the list. They will be ignored.
    >> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >> Help/Unsubscribe/Update your Subscription:
    >> http://lists.apple.com/mailman/options/cocoa-dev/<cocoa...>
    >>
    >> This email sent to <cocoa...>
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/development2%
    > 40bitblasters.com
    >
    > This email sent to <development2...>
    >
  • Hasn't this topic taken a tangent completely unrelated to Cocoa.
    There is nothing here that can be solved at the language level,
    wether in Cocoa, or any other language.

    This is purely a security issue that every developer must address
    when creating any type of secure system.  Wether that application be
    web based, desktop based, client-server database or web services
    oriented.

    On Oct 4, 2006, at 2:07 PM, development2 wrote:

    > Hi,
    > I need to turn off the ability to allow users to double click on a
    > file and have them open it up. There are security reasons for this,
    > as we do not want to allow students to open up the file and change
    > grades or attendance. So we have to go through our login procedure
    > that allows the teachers or administrators to open the file. But I
    > can not see anyway to turn this off. I know in Carbon this is done
    > through Apple Events, and ma sure that it is done the same way with
    > Cocoa.  I have looked on Apples site and searched this list, but
    > have not be able to find the answer to this.
    >
    > Thanks in advance for any help.
    >
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/robertwalker1%
    > 40mac.com
    >
    > This email sent to <robertwalker1...>

    --
    Robert Walker
    <robertwalker1...>
  • > Hasn't this topic taken a tangent completely unrelated to Cocoa.
    >
    Pretty much...
    Please take this elsewhere.

    Please also, though, send "administrative" messages to the list admins.
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today