I have got a passcode all up and running (4 digit login) and i need to get the option working so that the end user can assign their passcode in the settings.bundle.
At the moment, which I know is not ideal, I have a simple PSTextFieldSpecifier where the user can type in 4 numbers and login with those.
For reasons of security and having no control of what is typed into that field it will not do.
Where do I need to look to set up the screen for the passcode to be set up?
Cheers jeff
The settings bundle should be used only in a limited set of use-cases (as users often don't change individual app settings for months at a time, or not at all), and as such, limited control is given to developers as to the settings bundle and it's default controls. You'll need to use some kind of in-app settings, which are very easy to implement, and allow easier and faster access to something as variable as a username-password association. CocoaControls hosts a wide variety of simple frameworks and templates for in-app settings. I recommend you start your search there.
Related
In interface builder, there is a option that lets the user clear a TextField when they hit the (x) key. Since I think this option is extremely useful, I want to implement it in as many TextFields as possible.
However, the default implementation of the option is "never appears", and I want to keep as many default values as possible (because I think Apple considers the default interface behavior very well).
So my question is: when should I change the value? And if so, to what should I change it (always, when editing, or unless edition)? Here are some occasions I need to know:
On a table view
when the user enters his account details (email, password, name, etc.).
If you come up with other cases I should consider, please let me know!
Sorry, but I couldn't find any documents about this part of the UI in apple's documentation (which is very good and precise when it deals with standards).
This question is not about how to enable the key. Instead, it is when to enable it. I know it is my app and I can do whatever I want but I know how non-standardized apps feel like. So I want mine to be as standardized as possible so that the user doesn't experience any weird or usual behaviors.
This ABSOLUTELY depends on the you app design. Apple gives you these four options and it's up to you, which behavior fits your needs best, Apple does not care at all.
I personally only use it "while editing". In the past, I only used them for login or sign up forms.
I'm using Settings.bundle for few configuration settings for my app.
Now I'm searching for a solution to hide all, or even better, some configuration parts for the casual users. Only a 'admin' should see and edit these fields.
Is it possible to check for a password before showing the settings-properties?
If not, what could be a suitable solution? (new view controller with secret gesture or button?)
Thx in advance!
You won't be able to do anything special in the settings bundle. It's static, whatever you compile is what all users will see. If you want special behavior, there are two ways to do it:
Put it in the app itself and only allow the user access if they have the right credentials. A secret gesture could work too, but is a little dangerous because users may accidentally find out about it.
Use a different target/scheme or compile-time conditionals (using #if) to build two different versions of the app, one that does include the special configuration and one that doesn't. Personally, I would go for this option, but it may be a little harder initially.
Having googled, the general advice is to create a standard, non-administrator account.
I just tried that. I only had one account, my own, which is an administrator and then created a second (not the Guest account). I logged out of my own account and into the new one and tried to change the time. Windows 7 popped up a box asking if my main account would allow this (and prompting for its password).
I have been told "it shall not be possible to change system date/time". I intended to deliver a PC with only a standard account and my s/w, but can't (I think) prevent the user from creating an administrative account and changing date/time.
Can I prevent this programatially from Delphi, or do I just have to say that if the user wants to be destructive I can't prevent it?
Generally this kind of restrictions are set using the Windows Group Policy
From delphi you can use the Group Policy API or the RSoP WMI Classes.
In your application, you can actually detect user changing system time while your application is running.
You will receive WM_TIMECHANGE when system time change.
When startup, you can saved the gettickcount (As StartTickCount) and now (As StartTime). When checking, you can check if the different between tickcount and the different between time match (allow a small discrepancy) and know the different. However, if the user change system time away from your application, this trick do not work. Maybe you can have a service which is auto start checking for this.
If you need to change back to original time, here is some resources :
CHANGE the system TIME
btw, in OS level, a normal user cannot create an admin user.
I am new to JIRA.
Can somebody explain to me the meaning of the different schemes in JIRA; like issue security scheme, notification scheme and so on?
Helpful online resources are also highly appreciated.
A notification scheme maps email notifications to various events. For example: "When a defect is assigned, send an email to the assignee."
A Field Configuration Scheme maps Field Configurations to issue types.
A Screen Scheme allows you to choose which Screen will be shown to a JIRA user when they perform a particular issue operation.
An Issue Type Screen Scheme associates a Screen Scheme with issue types,
An Issue Security Scheme determines who can and cannot see issues.
A Field Layout Scheme allows you to configure which fields are visible and/or required fields for a given issue type on a per project basis.
For more details, check the Jira documentation.
I really appreciate the detailed explanations available at "The Grey Blog":
http://thegreyblog.blogspot.com/2010/11/atlassian-jira-configuration-tutorial.html
Most parts of JIRA configuration can be set up differently for different projects. Some things, like custom fields, can be also set up differently for any pair of (project, issue type).
The schemes are the means to configure these per-project/per-type configuration pieces, with probably reuse of one configuration among different projects.
For example, issue security feature allows you to set up options for Security Level field and limit issue visibility to certain users based on the value of that field. Issue Security Scheme contains definitions of those options and how they limit issue visibility.
So you first configure Issue Security Scheme (may be more than one) to define that piece of configuration, and then you can assign each project one of the available Issue Security Schemes (or neither one), thus applying those pieces of config to the issues in that projects.
Jira enables flexibility to customize issue types, fields, workflows, screens, permissions, security and notifications through schemes. You can create, assign and reuse these schemes to your projects based on your needs. These schemes are assigned to project's related schemes like plug and play.
Notification scheme -- You can configure notifications like email for the issues you create or issues assigned to you and any change in status
Field Configuration scheme -- Scheme used to configure fields.. You can set based on project. You can add more fields and add to particular scheme. You can even set restrictions (lets say if it is mandatory field or not)
Permissions scheme -- Used to set permissions for the project. You can name like Admin or general user and give what they can do
Screen scheme -- Used to add fields for a particular screen.
While others answered most of the points, I would like to throw some light on Issue Security Scheme.
This is the most versatile scheme where you can restrict accessing certain issues by the security level user has.
With combination of the permission groups and issue security features, you can do almost anything in Jira from a workflow point of view.
Well schemes are sort of mapping entities.
They contain the units, like workflows,screens,issue types.
Schemes will define how a project decides which unit to use for which issue/operation.
This is of course a high level explanation.
Best bet is to start experimenting with 1 scheme, let's say screen scheme. Once you get the hang of the scheme entity, every other scheme will become understandable.
My application needs to read an option on startup to check if it should start in read-only mode. The option should not be allowed to be changed by the user.
I usually do this now using a value set in the HKLM\Software section of the system registry. The administrator sets the value and the users can't change it (they don't have rights to modify entries in HKLM).
The problem is that on a terminal server (or Citrix) machine this affects all users. I'd like to figure out a way to do this on a per-user basis. How do others handle this? Is there a section in the system registry for this kind of per user setting that the user can't change?
Thanks for any suggestions or comments!
This is essentially what the HKEY_CURRENT_USER\Software\Policies key is for, i.e. a key within the user-specific part of the registry that is by default read-only to the user himself.
By convention the key hierarchy should complement the one you already have under HKEY_CURRENT_USER\Software, e.g. if your regular user preferences are stored under HKEY_CURRENT_USER\Software\MyCompany\MyProgram then the protected user preferences (or "policies" in MS lingo) should be stored under HKEY_CURRENT_USER\Software\Policies\MyCompany\MyProgram
Note that it is recommended to only set values under this key via Group Policy Objects and never by direct registry access.
The concept of a per-user settings area that the user can't change doesn't really make sense - if they're user settings, "you" (the user) expect to be able to change them.
I can think of two alternatives:
Write your settings in HKLM, but have
a different setting for each user and a global fallback setting for users without the setting set
Write them in HKCU, but use the
registry security APIs to prevent
them writing to it. You will probably need
permissions greater than theirs to
prevent them undoing the permission
changes. I don't really like this
option, but if you want to follow it
you probably want to start with the
RegGetKeySecurity and
RegSetKeySecurity APIs. This
article might be interesting as
well.
Personally I think the first option would be the easiest, and also would involve less dodgy stuff in the user's registry tree. Hope that helps!
How about two settings?
1) Set a flag in HKLM specifying that read-only is the default behavior on this machine.
2) For any users that need full access, set a token in HKCU which enables full access.
The token could be a cryptographic hash of some salt plus the username, so it couldn't be copied to give permission to another user.
Why don't you store options in your own database? It seems reasonable and handy enough (at least to me 8) ) No problems with making "portable" version of your product. No users bothering any settings you don't want them to bother.
Whats wrong with HKCU instead of HKLM? This would be per-user. Unfortunately it could be changed by the user if the user knew how to edit the registry and find the key.
Take one of the files coming with your program, that should not be altered (at least not by the restricted user). If there is no such file, create one just for this purpose.
Let the administrator set read only rights to that file for those restricted users.
In the program check whether you have write access to that file.