How to restrict access to salesforce application for the time users are on leave on basis of Leave start and end date?
Freeze user on leave start date and then unfreeze on leave end date ?
Any other automation approach ?
What exactly you want to achieve? Nightly batch job that does either of these should be enough? Not sure if you can do time-basrd workflows/processes on users.
You can (de)activate them although it's bit of a nuclear option. Other users might be impacted when they work with deactivated users' data, "operation was performed with inactive user" error.
You can (un)freeze manually or by modifying UserLogin table, each user will have 1 record in it. https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_objects_userlogin.htm
If you want them to be able to log in but do limited set of things - you could look at your sharing rules and temp change their role/group/whatever. Or change profile to read-only. Or unassign a permission set.
Then there are more sophisticated things like maybe disabling their SSO, having a login flow that checks something on user record, checking up addresses (like allow login only from office network, not from home). You could look into "high assurance sessions", multi factor authentication (take their work phone or RSA device when they go on holidays?) or there's interesting trailhead about detecting / preventing suspicious activity. https://trailhead.salesforce.com/content/learn/modules/enhanced_transaction_security and https://trailhead.salesforce.com/en/content/learn/modules/event_monitoring
I'm a programmer who is about to release an intranet site where apprentices can rate their educators and vice versa. Currently the system is working as planned, however HR wants some way to verify that the users are OK with their ratings. If not, they should be able to unlock their ratings so that the other person has to re-do the rating.
Unfortunately, HR also wants to reduce the amount of logins that these users have to endure. In the worst case scenario, users have to:
Log in to rate the educator/apprentice
Log in to unlock the rating
Log in to rate the educator/apprentice again
And so on...
The user who fills the rating has to be user A, while the user who unlocks or confirms the rating has to be user B. User A can also unlock the rating if they have a correction.
This process has to be done twice - once for the educator, once for the apprentice.
There is usually only one workstation present (factory environment).
Possible solution:
My suggestion is a kind of meeting workflow. One user logs in, clicks a button in the appraisal and the workflow starts. The other user is prompted to log in. This starts a kind of "double session" with both users logged in at the same time. This is a way to verify that both of them are present in a meeting.
This process could be used for multiple ratings at the same time, guiding the users through the process one by one.
HR wants both of them to meet and discuss their ratings.
Are there any security and/or best practice concerns that I should be aware of? The system has to be ready on the first of August, so I'm really hoping to solve this issue as easily as possible. Are there better ways to do this?
It turns out that my idea of logging in two users at the same time wasn't so bad. At first, a regular user logs in and launches the meeting mode. In order to verify that the other user is present, this second user logs in. Both user's data is now stored in the session and the meeting workflow launches, guiding both of them through their appraisals. When the last appraisal is finished, the second user is logged out.
This question is solved.
Are there any "design patterns" related to processing important financial operations so that there's no way that a local database can become out of sync because of some errors ?
Example:
A financial transaction record is created in a local db, then a request is sent to a remote payment API endpoint to charge a customer. Pseudocode:
record = TransactionRecord.create(timestamp=DateTime.now, amount=billed_amount, status=Processing)
response = Request.post(url=remote_url, data=record.post_data)
if response.ok:
record.mark_as_ok()
else:
record.mark_failed()
Now, even if I handle errors that can be returned by the remote payment service a lot of other bad things can still happen: DB server can go down, network connection can go down etc., at arbitrary points in time.
In the above code the DB server can become inaccessible right after creating the transaction record, so it might not be possible to mark that record as ok, even if the financial transaction itself has been performed successfuly by the remote service.
In other words: customer is charged but we don't have that booked..
This can be worked around in a number of ways - by periodically syncing with the remote service, by investigating TransactionReturn-s which are being processed but are older than e.g. 10 minutes or an hour.
But my question is if there are some well established patterns for handling such situations (where money is involved, so everything should work properly "all the time") ?
PS. I'm not sure what tags should I use for this question, feel free to re-tag it.
I don't think there is any 'design pattern' to address cases such as database connection going down or network connection going down as it happens in your scenario. Any of those two scenarios are major fault events and would most likely require manual intervention.
There is not much coding you can do to address them other than being defensive by doing proper error checking, providing proper notifications to support and automatically disabling functionality which does not work (if the application detects that the payment service is down then 'Submit payment' button should be disabled).
You will be able to cut down significantly on support if you do proper error handling and state management. In your case, the transaction record would have to change its state from Pending -> Submitted -> Processed or Rejected or something like this.
Also, not every service provides functionality to for syncing up.
In my web project, I am storing mail addresses. These addresses may be used by the system to throw mails to the recipients. It is also important to say that these mail addresses have expiration time.
But the critical point is trustness: for this very service, people must be sure that the mail addresses wil not be given to somebody else (especially to authorities, for example).
To resume:
the system has to "know" the mail address.
the webmaster (or somebody else) has to be unable to find the true mail addresses.
By doing this, the webmaster will not be able to give information (even by force :)).
Intermediate solution: I already know how to do this as soon as the information has expired. E.g. The mail address is encrypted with gnupg (GPG / PGP algorithms). The system (or anybody) can decrypt if he/it has the password. But as soon as the mail address has expired, let's revoke the secret key :arrow: one cannot decrypt the mail address anymore.
But this raises a performance problem (to create the private key)...
Any help would be most appreciated !
What you're asking for is impossible. Even supposing you could devise a system whereby the system can send emails without being able to reveal them to an administrator (and you can't), an attacker could simply start a mail run and capture the outgoing emails and extract the addresses before they're sent.
If you want to 'expire' email addresses, you should simply delete the records, then (if you're paranoid), compact the database and erase the free space on the disk.
We are using standard items such as Hard Disk and CPU ID to lock our software licenses to physical hardware. How can we reduce the risk of customers installing onto a virtual machine and then cloning the virtual machine, bypassing our licensing?
One approach is to have a licensing server. When you enter a license code into the client (on a VM), it contacts the server and sends it its license code and other information. It contacts it repeatedly (you define the interval -- maybe once every few hours) asking 'Am I still valid"? Along with this request, it sends a unique ID. The server replies 'Yes, you are valid', and sends a new unique ID back to the client. The client sends this unique ID back with its next request to the server. The server verifies this is the same ID it sent to the client for that license, the previous request.
If the VM is duplicated, the next time it asks the server 'Am I valid?', the unique ID will be incorrect either for it, or for the other VM. Both will not continue to work.
You will need to determine what to do if the server goes down, or the network goes down, such that the client cannot communicate with the server. Do you immediately disable your software? Bad idea! Don't make your customers angry. You'll want to give them a grace period. How long should this be? A few days? Weeks?
Let's say you give them a 1-month grace period. In theory, they could clone the parent VM just after entering the license key, then restore the other VMs to this clone just before their grace period runs out, disabling network access to them. This would be a hassle for your customers though, just to have pirated additional copies of your software. You have to determine what kind of grace period won't hassle your legitimate customers, while hopefully giving you the protection you seek.
Additional protection could be achieved by verifying that the VM's clock is set correctly. This would prevent the above approach to pirating.
Another consideration is that a savvy user could write their own licensing server to communicate with the VM instances, and tell them all 'you're good' -- so encrypting the communication could help deter this. How far you want to go here really depends on how much you think pirating really might be an issue with your customers. In the end you won't be able to stop true pirates who have time on their hands, but you can keep honest users honest.
License. Tell your users, they may not run unlicensed copies.
We are actually failing to buy a license for a software at the moment, because the vendor is scared of virtual machines: The infrastructure for our department is being moved to a centralized virtualized sollution and we have to fight the vendor to be allowed to buy a license for his software!
Don't be afraid of paying users.
People too cheep to buy licenses are going to look for another sollution and will be too much hassle anyway.
(good luck telling your boss that, though...)
There is no good reason to lock to a physical machine. Last I checked computers can break down, and then the user is probably going to be inconvenienced not only by a dead computer, but by having to call you to get the software locked to a new machine. If you must do draconian license management use a (local) management server and have running copies verify that they have a license every few minutes. Just realize that whatever you do if someone really wants to use your software without paying you they will find a way.
You need something outside the computer "hardware" to authenticate against. Most companies choose hardware keys (dongles) in for software with a high cost where users will put up with it.
Other companies use online methods - if more than one user with CPUID and other hardware is concurrently using a given license, then disallow another instantiation, or close the existing instantiation.
You have to choose protection according to your needs and the consumer's willingness to jump through your anti-piracy hoops.
-Adam
There's not a lot you can do AFAIK, except require periodic online activation.
We have problems with people Norton-ghosting physical machines. Apparently HDD serial numbers are ghosted too.
If your software runs under a VM, then it will run under any number of cloned VMs. Therefore, the only option seems to prevent it running under a VM at all. Here's an article about virtual machine detection: Detect if your program is running inside a Virtual Machine and one about thwarting it.
By the way, cloning a VM is usually enough of a hassle to deter casual users from bypassing your licensing and those hell bent on cracking will probably find a way to bypass it anyway.
"Don't bother" is the short version. It's non trivial enough for your clients to do it that if they are doing that, then either they won't pay for what they use no matter what (they will not use it unless they can get it for free) or you are just flat charging to much (as in you are gouging.)
The "real" customer will generally pay for the stuff. From what I've seen, places like businesses will generally consider it not worth the effort.
I know some virtual machine software (at least VMware) have features that allow software to detect virtualization. But there is no foolproof way, it's possible to patch such features away anyway. Mysteriously changing performance (due to CPU spikes in the host) could also be used, reliability is questionable. There is a plethora of "signs of being virtualized", but they tend to be not 100% reliable.
It is a problem, and any savvy user will be able to defeat pretty much anything you do about it. Unsavvy users might get caught by behaviors like VmWare's player that changes MAC and other IDs of the virtual machine when you move it, presumably in a nod to this kind of issue.
The best solution is likely to use a license server instead, since that server will count the number of active licenses. Node locking is easier to defeat, and using a server tends also to push responsibility onto an IT department that is more sensitive to not breaking license agreements compared to individual users who just want to get their job done as quickly as possible.
But in the end, I agree that it all falls back to proper license language and having customers you trust somewhat. If you think that people are making a fool of you in this way, you should not be selling your software to them in the first place...
If your software was required to under on a VM what about this concept:
on the host machine you create a compiled program that run eg. every half hour, which reads the Hard Disk and CPU ID, and then stores that together with the current timestamp in a file together with a salted hash of all that information.
you then require that the folder with the file is shared with the VM.
in your compiled software within the VM you can then read this file and check that the timestamp is recent and the hash is valid.
Or better yet, have the host program somehow communicate with the software in the VM directly.
Couldn't this be an okay solution? Not as secure as using a hardware key (like Yubikey) but you would have to be quite tech savvy to break it...?