I have recently been tasked with finding a suitable installShield replacement and I am leaning towards InstallBuilder over Install4J and InstallAnywhere. Has anyone come across any issues with creating installers that installBuilder has been unable to handle? For example very strict security on the client machine.
*Comment added for additional clarity
For instance a system that has all accounts disabled sans the admin account with a very unique domain policy for instance, the inability to write files to the temp directory. Also how extensible is your product, from playing around with it I notice it is purely xml so is there anyway to write some extensions to the core?
this is Daniel from BitRock. Our installers do not need admin privileges in any platform (unless you explicitly require them) and can install as regular users. If you need to check permissions in the filesystem, registry, etc. from within the installer to see what is available, there is code to do that as well. I am not sure if the above answered your question. Can you provide more details about what you mean with restricted security in the client side? We take great pride in our level of support, and we encourage you to contact our support team with any questions or suggestions you may have, just to see by yourself.
You should also take a look at InstallJammer just for comparison. It's a lot more open than most of the ones you mention and gives you the ability do practically anything from within your installer.
Related
I am learning SharePoint and the different kind of solutions you can deploy. From the training I am watching it seems like you should try your best to use a Sandbox Solution when ever possible. This is because Farm Solutions can mess things up too much.
However, two of the main things I would do with WebParts are not supported in Sandbox Solutions. Those are Visual WebParts and WebPart communication. (The first is not allowed because it needs to hit the file system and the second is disallowed because it uses reflection).
It seems to me that my WebParts will always want to do at least one of those things. (WebParts that don't communicate are not really that modular are they?)
Am I missing the point or are Sandbox Solutions a "nice idea" that are not really used in actual code?
Yes, I agree with you that Sandbox solutions are very restrictive.
But, it is that restriction that gives them their value. Due to the restrictions a Sandboxed solution cannot bring down a farm (atleast that is the theory, someone may find a way to do it).
This means that you can open up to many more users to deploy things on the farm. It is also a requirement to deploy things to SharePoint Online.
That Sandbox solutions are more restrictive, means that development is more cumbersome, you have to program your way around the restrictions. This makes solutions more expensive. Therefore, the default should be farm unless you have a good reason not to use it.
I think some of the comments here are missing the entire point of a Sandbox solution, they have been deliberately given a reduced set of privileges for many reasons:
a) A site collection administrator can add a SB solution hence they need not be farm admins therefore better security of the farm.
b) You can trust that an SB will NOT bring down the farm, they don't even run under the normal SharePoint worker process, instead they are hosted under their own process that acts as a host to check to see if the resources accessed are allowed for an SB solution.
c) The cloud is coming, there’s no getting away from that fact, when somebody else is hosting your SharePoint solution do you really think you'll get access to the farm?
I think understanding the impact of running as a Sandbox Solution from a non-developer perspective is important, after all you wouldn't create a custom solution of any kind and expect the customer to grant you domain level accounts to run it, therefore when creating SharePoint solutions, think running your solution with the minimal amount of permissions by default, if there is really no other way then explore farm solutions.
Here's a useful guide from MS:
http://msdn.microsoft.com/en-us/library/ff798382.aspx
If your environment allows you to install farm solutions, then yes, sandboxed solutions are restrictive and stop you doing what you want.
However, if your environment does not allow regular solution deployment, as is the case with shared hosting and some large corporates then they are not restrictive because without them you wouldn't be able to use custom code at all.
Sandbox is horrible, i totally disagree with the statement "it is that restriction that gives them their value". you cannot do a many thing in sandbox.
1. no session
2. no web-part communication
3. no file upload controls
4. no redirect...
and it just makes things painful as hell. we are in the midst of developing an enterprise application facing outside users, my advice, if you considering Sandbox for these purposes, i would say add 150% more time for your project just to deal with sandbox issues.
most people talk about benefits, but all the benefits are not really benefits.. for example, if even a single sandbox application code raises exception which is unhandled... good luck, it will crash the entire farm, and tracking the issue is real nightmare.
if you can stay out of sandbox
I have a number of Windows servers at work that are used for staging web sites for clients while they are being created.
I wanted to start using versioning on them so that when we work with outside vendors on a project, if/when they overwrite my work, I'd like to be able to go back and get the version before.
My question is that I think I'm not looking for the correct terms in searching for information, but what kind of resources are there to learn how to install the software for versioning or a site to help me get started.
Any and all suggestions would be appreciated.
Steph
Since your development workflow can be decentralized (as in "there isn't always one central repository), DVCS tools, with their common tasks described here) can be more adapted.
Git-Scm
Mercurial (see HgInit.com for a very good tutorial like the kind you are after)
Plastic SCM (which has a DVCS nature)
I would like to have your opinion about the subject "version control",
but focusing on security.
Some common features:
allowing to access to source code using clients only
(no way to access the source code on the server directly)
granting permission to access only the
source code which I am allowed to modify (i.e.: a developer should be able
to access the source code related to his project only).
So it should be possible to create user groups and granting different
levels of access.
tracking modifications, check-ins, and check-outs and the
developers who made them...
...and, surely, I am forgetting something.
Which are the most "paranoid" version control systems that you know?
Which features do they implement?
My aim is creating an enviroment for developing applications managing sensible data: credit cards, passwords, and so on...
A malicious developer may insert backdoor or intentionally alter some security features. So the access to the source code should be controlled strictly.
I must confess that my knowledge of version control systems is poor, so, I fear, customizing SVN could be a hard task for me.
Thanks
Perforce is widely used in the Finance Industry where security of code is sometimes an issue.
You can setup gatekeepers and access controls to restrict visibility of code and produce audit trails for various activities for SOX compliance.
I know that the ones you want are not the ones you want. For example, Clearcase or Serena Dimensions can do all the above... but you'd be bonkers to want to use them. (ah, I hear you say, I'm the admin so I don;t have to take that pain. Well, these also require lots of care and attention - we had 8 Clearcase admins at the last company I worked for. You don't want the nightmare of continually helping users with them).
So. You can have the horrible ones, or you could just use the friendly, easy-to-use SVN and implement your own checkout-tracking (using http transport and Apache logs), and slap access control permissions on every directory. You'd also have to secure the end-repository on disc, but you have to do this with every SCM, even something like Dimensions stores its database in Oracle - if you had access to Oracle instance, you could fiddle with the saved bits, so you have to secure that anyway.
Perforce has those features and is a really good product imho.
Use a well-known, industry standard system like subversion. It can control access to individual projects very simply, and using the web server authz configuration can control individual access to specific files in each project.
The only non-stanard issue is logging check-outs. But the web server can easily log this information for you.
Your users will thank you.
github is a wrapper for git which provides these features for git server. Compared to raw git servers, it notably includes access control, and it also has useful web interfaces to the code for authorised users.
From a usability perspective, is it better to integrate admin section on the main website or have a separate section to manage content?
Any thoughts are greatly appreciated.
EDIT: the application is a CMS for very non-techno friendly staff.
It depends on the project and part you want to administer, imho.
For example comments on newsposts should be administered in the website itself by showing a "delete" linkbutton for each comment. Otherwise the mods would have to look up the comment in the admin section => not very user friendly.
But in general I think a seperate admin section will usually be more clear to your client. You'd want them to see the site as a normal user would see it.
At the very least I would recommend moving all your administration files to a separate folder. That way if you're using a platform like .NET you can very easily control folder access though role and user-based web.config permissions.
Having your administration files all segregated allows you to do other things easily too, like delete them if you decide to move them to another server later. Also you can exclude them in your robots.txt file (although by putting it in the robots.txt file you will be telling other people this section exists, and robots don't have to mind this file).
Edit:
I feel like my answer missed the mark a little considering your question. Of course in-line editing is easier than going to a separate page from a usability perspective, but whenever I hear of mixing admin users with regular users giant alarm bells go off in my head.
I think that it depends on the function of the site and how intrusive it will be to your staff. Does it make sense for them to make changes while browsing the site and will they eventually become discouraged with your system because it forces them to inject unnecessary steps into their process? How long will the edits take? Does it make sense to show a completely different interface to administrators? I think an answer to this question requires a lot more understanding of what specific function you're trying to accomplish and will vary on a case by case basis.
I have never liked adding administration pages into the main site. It seems like it is too much of a risk from someone accidently getting access to the administration portion of the site. Even if you review the security over and over, there is always that possibility that something unexpected will happen, and it is a huge mess to clean up (what was modified, who accessed what etc. etc.). In my opinion keeping it as a seperate site is the easiest way to go.
While there is a level of convenience in being able to login to the main part of a site as a privileged user, and then clicking on parts of a page to edit/alter it, there is also a measure of security in having it in a separate area.
I have found that having a separate section of the website that is devoted specifically to administrative tasks makes the tasks easier to organize and use. Just look at Wordpress (especially the new 2.7 release), Drupal (a very popular cms), and Joomla (another very popular cms). If you would like to test these feature out to see why I think the separate section is better, you can go to www.opensourcecms.com and test out both Drupal and Joomla.
From a usability, the more integrated the better but it tends to add severely to the complexity. Its always best if you can perform the action within the context in which it occurs - lock out a bad user, trim a log thats too big etc. however since these tend to have significant side effects the security aspect trumps this a lot of the time out of fear.
I think you need to look at doing a risk assessment with regards to integrating the administration capabilities right into the application.
What would be the implication for the system if someone were able to escalate privelages and gain access to the admin functions. if every user was locked out maliciously - damage to the site, the reputation, SLA etc?
What destructive functions can an admin perform from this section ? delete lots of data? crash the app? alter costs that have material impact on users/customers?
Are the admin functions integrated in the app or isolated into specific admin functions?
Does the application have a public face or is it an intranet that is assumed secure?
I personally have never felt at ease integrating the admin section with the site out of fear that a security breach caused by my ineptness or something beyond my control like bad defaults, unpatched exploit. However, when the client is writing the cheque I tend to do what they feel is best.
I come from the school of Usability that says "minimise guess work". So, what kind of information did you get from your user group sessions?
Remember, you're not (and we're not) typical users of your system. Anything we say is going to be a guess. What's worse is that any opinion shown here is likely to be ill informed for your situation (but probably awesome at what they do). The only way you'll have an informed opinion on what to do is by going out and asking your users in intelligent ways.
Because this is a security issue some of your user mix should be people who specialise in security. Just because it's easier to use doesn't mean it's the most appropriate.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
It would seem to me that many large enterprises already have robust directory services such as Active Directory and it would be silly to constantly duplicate users in an application-specific store.
Even if you require duplicating the user store, you can provide a mechanism to authenticate against Active Directory. Alternatively, you could support a standards-based SSO mechanism that leverages SAML.
Support for the XACML protocol. Duplicating information on roles and entitlements is equally insidious.
Support for the SPML protocol. Many enterprise leverage identity management toolkits and would at least like out of the box integration in terms of centralized management and provisioning.
So, why aren't open source projects considering this type of functionality as a default to getting on the radar within an enterprise context?
Lots of reasons, but one of the biggest is that there's less convergence on what the right or best methods really are than you seem to believe.
Active Directory, for example, is kind of notorious for presenting implementation difficulties to non-Microsoft developers.
There are probably a half dozen competing single-sign-on "standards".
It's very difficult to reconcile different roles/privileges models -- hell, Sun has trouble reconciling the models of Solaris Trusted Extensions with the Java model.
Solving those problems isn't a lot of "fun" and so FOSS developers are attracted to other issues.
I think that Charlie nailed it:
solving security problems is hard and generally not a whole lot of fun
OSS developers tend to be all about enjoying what they are working on. I work on a number of "enterprise class" efforts as part of my professional life and I will agree that they are not a whole lot of fun. However, this is one of my never ending griefs with OSS components... we have trouble using them in our solutions because they do not meet our customers needs.
I think that the general reasons are:
universities tend to ignore this aspect of "enterprise development"
too many standards to choose from
no clear market leader
the different security providers are difficult to configure and test
the entire application security paradigm requires a lot of expertise before you can even start trying to integrate
Personally, I blame the first one. Most engineers do not even consider how an application can be used in a larger context. They are interested in solving the problem at hand and not at all interested in providing a usable solution. Most FOSS solutions are very much an interesting solution to an interesting problem. A corporate entity normally comes along and provides the commercial packaging that makes the FOSS solution actually usable in a real environment. Of course, this packaging comes with a price tag attached.
Open ID is a start towards providing an "authentication" solution. (To the best of my knowledge, it has no "provisioning" mechanism, though. You have to trust the external authority to identify an account, then add your site's / app's version of that account using your own devices)
If anybody knows of some kind of open "authorization" solution to centralize the management of roles, that would be interesting as well. That sounds like the sort of thing you would do in-house, though, with roles that have a defined meaning in your organization. I'm sure IBM or Oracle would be happy to take a big chunk of change and make something for you, though :-)
You may not want to have your active directory / LDAP contains the role of all your users for all your applications. If you have a lot of movement in your structure, you may have a lot of daily modification going on.
Also, the information in the user store may be quite specific, and may not have its place in a global repository.
Least, the notion of role can be quite variable. We have three application that possess the notion of "mananger", each one having a slightly different definition of what is a manager and who he/she is managing.
regards,
Guillaume