I want to create a centralized Release Management server, for our customers but in my tests I'm not able to secure that our components will be safe from change mistakes. For example:
My test was like that:
User 1 - Release Manager (with all permissions)
User 2 - Ordinary user (just permission for approvals)
Logged with my User 1 - Release Manager (with all permissions)
First of all I ensured that only Release Managers will have access, and be able to see that release template:
I created a new component:
Then I logged with my User 2 - Ordinary user (just permission for approvals)
Firstly I can't see the release template I set permissions above in the release template list. Then I went to the components list and I'm able to see the same component, and even change it.
The main problem is that after done that, it impacts the releases for all release templates that contains that Component.
I hope to be wrong, and that someone should clarify it to me, that we may secure somehow all components with permission and so on. Any ideas?
Adding security for components is on our backlog. Thanks for the feedback. vNext components do not have tool or execution command stored in them. So, they are a little safer from this issue. Nevertheless, they do have configuration, and you would want to protect that configuration. This feature will be added sometime this year.
Related
I am using DNN 9.3.2 and Evoq 9.3.7.
I would like to paywall content in a section of the website with teaser content i.e. so that they can read a part of the article but need to pay/ log in to access the content. 'Members' would also need to be able to log in and bypass the paywall. Users would idealy be able to manage their account from here. The paywall would also need to be able to handle a complex pricing model i.e. different prices for different user types, possibly different content available for different user types.
Would anyone be able to advise how best to do this with DNN/ Evoq, and which modules from DNN store (if any) would be useful?
Thanks!
I have never tried this, but in theory any shop solution should give you that functionality. Have a look at OpenStore, which is Open Source and free.
Or a News/Blog module that supports paid content, as EasyDnnNews.
I believe you'll have to brew your own or ask a specialist who knows what they are doing already. The basic principle is as follows:
Protect a page with a role - let's call it Patrons which only paying users will get
Create a page for users to pay on, and if successful, assign them the role
You can also do things like ensure that the role is only given for a certain time, and then the users must pay again.
If you have a subscription model, you would probably run a timer job or something to verify payments have happened again, and if true, extend the role assignment
I started working for a company in the field service industry. We have a program and client database build in Access. As of right now, they are scheduling their service calls in a notebook. I am trying to get this company into this era by having a web-based scheduling software.
I have basic schooling networking but I am not a programmer nor do I know Access. I have learned how to split the database and create a multi-user environment and converted it to accdb from mdb to work with Access 2013 instead of 2003 in which it was written. These steps have greatly helped but I am not sure where to go from here.
My next step is the scheduling software but the company's greatest concern is the protection of their client database. Not from outside hackers but there is always a concern of employees selling our client list to our competitors. Also, at this time, employees do not have web access for this reason, which they will need.
Is there any way to keep the accdb file from being sent via email etc. or copied to external media? If I set up permissions through the OS, won't that make the client files uneditable (for lack of a better word) in Access? Like address/tele # changes or notes? I'm not even sure what to even search for help.
Thank in advance for your time
I understand that Access 2013 can be installed on a Server 2008 R2 or 2012 server. Put a password on the database. That should keep hackers out, and as far as keeping employees out of the data that they shoudn't be in, I know the navigation bar can be hidden, but it is unfortunately able to be viewed again by the F11 key. It would've been nice if MS could have made the navigation bar ability an easy option (yes or no), and make it modifyable in VBA....They may have. Keeping users out of raw data is something I have yet to figure out too....
I'm a novice at this stuff, but I was able to write code, and a login screen of my own so that users can have their own login ID, and a password (or phrase), and enable them to change their own password if they forget it, or if they just just to change it. You can make the navigation bar disappear by the VBA code: DoCmd.LockNavigationPane True...but unfortunately F11 can re-enable it.
Hope this helps....
we have multiple features that needs to be developed but management decides which features go into Live.. this requires us to have a script for each User Story/Change . But how can I link a DB schema change to a User story in TFS?
What we have now:
TFS with User Story/Task
CC.net Buildserver
I've done research for SSDT, looks awesome! but how can i Link this with TFS?
thanks for reading,
Andy.
As long as your database scripts (or SSDT projects if you choose to move that direction) are checked into TFS version control, there is a deep connection between changesets and work items. When looking at your pending changes before checking in code, there is an option to associate a work item (i.e. a User Story or a Task). If you are using Visual Studio 2012, this is what associating a work item would look like:
And this is what it would look like if you are checking in via Windows Explorer:
There can be a lot of complexity associated with making changes to a system independent of each other. The best solution I've found involves creating "feature toggles" so that you enable or disable a feature after it has been deployed. Take a look at continuous delivery as a topic. Jez Humble wrote a great book on the subject.
Database schema changes can be more complex in some cases than just enabling or disabling a feature. I would suggest using an expand / contract model. You would add any new structure to the database in advance and get that deployed into production in a non-breaking way. Then when you enable the feature that has a dependency on that structure, it's already there. If you need to clean up the database schema after you've removed something then you could do the "contract" cycle out of band with other software changes to reduce the surface area of test.
I have an windows application (WPF) in which we are running on each login, however when the user first logs into a new PC the application will need to do some specific tasks, but only on the users first login and never on subsequent times.
Is there a way in .Net 3.5 to query wether the user has logged in before (ie some kind of login count)?
Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.
We use redirected folders so the user may have already logged into a PC on our network these special events should only occur when the user hasnt logged in onto the PC and Windows has had to create a new profile for the user on the PC.
If I am not clearly explaining what I am seeking, please dont hesiate in letting me know.
Matt
Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.
I'd recommend going with this option. Don't try to detect it, just create your own state on first run.
I suggest this, not because it is technically impossible to achieve the functionality you describe, but because it is a better user experience. It provides an easy way to re-do the action without having to recreate the user.
... a txt file in the users registry ...
I'm not sure what this means. You can create text files under the user's profile directory, and you can insert string values in the registry (but not files of any sort).
As for the particular mechanism, I suggest you consider:
An App.Config value. Clearing out the value is easier to support or batch-script than a registry value, and makes the user less scared that their machine will explode if you have to tell them to edit the settings. Users are scared of the registry.
A sentinel text file under the user profile directory. Wiping out the file is super-easy to support and batch-script. Instead of editing a text file, they can just delete one. But this makes it so you have multiple config mechanisms, so multiple points of failure. I'd only do this if I were using the App.Config for additional settings in the program and thought the user wouldn't be technical enough to hand edit it.
The windows registry. Remote registry access might be easier than remote file access, if you're having to do remote troubleshooting. It also might be easier to mess with via group policy, in case this is an intranet app and you need to force a re-run on all machines in your org.
I'd carefully consider my options and which is most likely to ease support (be understandable by my users) before committing to one. I'd also consider the remote-troubleshooting/remote reset scenario.
This may not be what you're looking for but I'm hoping it will help you anyway.. I do not know from the top of my head how to do this in WPF but I do know you can use an "unattend.xml" file and the FirstLogonCommands to execute a script or application on first logon. I have used this for Windows 7, it may not apply to XP.
I'm a developer at a small company where we're struggling for consistent change control. I'm running into issues where non-dev staff are tweaking stored procedures and triggers in production installations. Their changes are being overwritten when we apply upgrades because they've gone outside of the process the dev team uses to verify db changes are incorporated into source control.
How would you recommend approaching this problem from a technical as well as personal perspective?
Edit 1: A little background on our current process might help this along. We're using a continuous integration server (TeamCity) to generate install artifacts and label svn upon check in. I'm using NMigrations to manage schema and sp/trigger changes when we apply fixes. Unfortunately it's beyond my ability to stop unauthorized schema changes so what I would love to find is a design pattern that allows for an overridable trigger/sp definition.
You need to clearly separate:
source control management
release management
Tweaking in prod shouldn't be possible if the release environment is protected through strict ACL preventing anyone duly appointed to deploy and change stuff.
If that deployment process is automated, then all changes will go through the proper channel because anyone will known a simple "push button" process will be enough to deploy the hotfix.
But if getting that fix in source control and deploy it is complicated, then a tweak directly in prod is usually the result...
Limit rights to change stored procedures and triggers, especially on production. Go ahead and let them know first so they aren't blindsided, but clearly protect production from all unauthorized changes.