I'm starting a new site for a client. They have different user roles depending on what account you sign into on their site. Some users will see all options others won't. Some will see options that other accounts can't and vice versa. I was wondering if I will need a separate view-page made for each type of account or if I could use one view-page but lock specific people out from seeing specific things on their page. If able to do either way what would be the easier/recommended of the two.
I think you should use second variant, cuz support a few page very hard. So if you chose second variant you just use #if(isAdmin){one html} else {other html} in your view page.
Related
This question already has an answer here:
Can a use-case include and precondition the same other use-case?
(1 answer)
Closed 4 years ago.
Scenario: To use my application you need to login first (get an access token), then you are able to use my application. If you're not logged in. You will be shut out.
So, when drawing my UML Use Case:
do i link my actor to the "provide login" use case?
or
do i provide an includes from the other use cases to login?
A bit confused as I have been taught that its not the goal of the system to login, but what if you cant use it if there is no login credentials passed. So just need help on being clear in that understanding.
Thanks
A Use Case has to provide the user business value. “Provide Login” is not really a Use Case, since it doesn’t do anything useful on its own (the user wouldn’t login and then do nothing once logged in, that wouldn’t make sense) so it is more simply just a function of the system. The user being logged in should instead be modelled as a constraint (e.g. pre-condition) for your other Use Case (constraint being end user identity is authentic etc).
That said, though it’s not correct, some people decompose their Use Cases into functional blocks, and model a “Login” Use Case and then (usually) “include” that into their main Use Case (option #2 in your list). This is done usually so that the Use Case specifies precisely the expectations of the Login process (steps), however this is often more of a problem for the system architects/designers and programmers than a help (there are many ways that an end-user could be authenticated and the way it’s achieved may not be common across all end-users even within the context of just one system).
Login is no use case since it does not add any value. And use cases are simply about added value the system under consideration delivers to one of its actors. So rather than adding a wrong Login use case you should attach a constraint { must be logged in} where appropriate.
Again I have to recommend Bittner/Spence to get a full understanding of use cases.
Thank you for looking into this! My boss asked me about the following: We are in a library and we have online access to journals. When someone requests access to a journal, we log them on. If this has to be done for a whole class of students, it takes quite some time.
Let's assume we have a Csharp application. The application is in the C:/Program Files/ folder together with some kind of configuration file that contains the credentials and URLs and so forth. Since the files are in the C:/Program Files/ directory, a regular user will not have access to copy/manipulate any of the files. Using the CSharp SecureString class, the credentials would be safe. However, as soon as the application opens the browser and uses HttpWebRequest to send a POST request to log us in, the data would not be safe anymore.
Is this correct? A regular user can start an executable and could gain access to the POST data in the browser or can maybe impersonate the browser to get the POST request data.
If this is the case, I have two questions. The second one may be a question about opinions but the first one shouldn't be.
Is there any way to do what my boss wants me to do safely without ever giving anyone access to the credentials?
Is this a bad idea and should not be done at all?
I am also happy about "You should not do this, because..." answers, because this would also solve the problem for me if I can convince her of this.
Thank you!
Edit:
Sorry for the lack of information: Different accounts are used. Most of the time, it would be the student's own domain account. We also have a generic domain account we sometimes use in the library for classes to have the computers already logged in when the class arrives to speed things up. So this is a well known account. Of course entering the credentials in front of the patron as we do now is in no shape, way or form secure either.
It is a provably unsolvable problem. Since the user's machine, in your setup, needs to know the sensitive information, there is no way for you to prevent that machine's user from also knowing that sensitive information. The only way to prevent the user from accessing it is to ensure that the sensitive data is never on the client's machine.
Pretty much any "good" solution is going to require some sort of cooperation with the site in question, which you presumably won't have. Good solutions would involve having a server only you control (with the "real" credentials) log in, and then provide some sort of temporary token or session ID to the user to use for a period of time, and that would expire after a short while.
Another option is to never have the user directly access the site, but rather always access a server you control which will redirect all traffic (that you consider valid) over to the other system. While this is an option that would be possible without any cooperation from the 3rd party, it likely wouldn't be terribly trivial to implement.
I'm pretty inexperienced when it comes to working with IIS, so I apologize if the question is a bit confusing.
In the application, I have a Controller with a method called 'Login' that takes in a string parameter. The parameter identifies the organization the user is trying to authenticate against.
For example:
http://mysite1.com/Login/12345
Visiting this link brings the user to a login page for the organization that is associated with '12345' for their access key.
Is there any way to redirect users that are logging in under '12345' to another server? We have a few beta users that are willing to participate, but the database schemas for both servers are different, so it's important that the beta users are not hitting the wrong site.
After the user logs in, the access key is no longer in the URL, so I can't do matches against it.
I'd like for the user to see the following URL:
http://mysite1.com/Login/12345
http://mysite1.com/Products/
http://mysite1.com/Admin/
While in reality they're on a different server:
http://mysite2.com/Products/
http://mysite2.com/Admin/
I have to emphasize that I really do need the URL to stay 'mysite1' for the user, when in reality they'll be on 'mysite2'. Please let me know if this is possible or not, or if there's a better solution for it.
Sorry if this is a confusing scenario or if there's some information that I'm missing. I'll make edits if necessary.
Virtually anything is possible, but this approach seems really painful.
IIS can perform URL rewriting but it's going to be doing this before it hits the authentication layer so it will not be possible to differentiate users at that level.
It seems like the best option will be to write a custom URL rewriter provider. Looks like this post is attempting to solve it that way.
It really seems better to either redirect to a different server (which I know you're saying you can't do) or merge the multiple versions of functionality into a single app (with different controls/backend models, etc.)
This link may help in understanding a little bit about how the flow works in an ASP.NET MVC app.
I'm writing this application where I want the (Admin - Developer) have more control of the app than the "regular" users. Let's say, a button will only be shown to the Admin if a setting is enabled.
So I was wondering about how to make 2 different versions? Only way I can think of right now is to first write the "regular" and release it, then re-add the code/features I want the admin to have.
Maybe a setting somewhere or something that can be enabled/disabled during publish that can make life easier? Any help/tips will be greatly appreciated.
Edit: I've just set a setting in the Settings panel (Setting True/False) and using the Properties to allow/disallow features. If anyone knows of a better way please reply!
First you should clearly identify the tasks of the administrators for example user related tasks like creating users, deleting users, giving permissions, resetting passwords and configuring database connections may fall in to this category. Then you can create a separate set of interfaces/ windows to handle this tasks, you should enable these only when an admin is logged in. That is the easiest way to do it. After you have identified the admin features you have the option of creating a separate app for the admins as well.
And if you have some features which you can't separate out of the regular forms like if you have button in a regular form which only gets enabled for specific user I think you should use settings based approach.
It depends on how significant the UI differences are between the two user groups.
Generally, you want to maintain the least amount of code, so the drive is to avoid code duplication, so you won't have to maintain three files with the same logic or ui elements in them. (I assume ASP.NET: User controls are really good to deal with this.)
Second, do not make logical decisions on who the user is, but rather abstract it out and base logic on what a role can do (i.e. permissions). For instance: when processing a page and hiding/showing elements, base the decision to show the "delete" link if the user has the "DELETE" permission.
the company I work for want to use a "hosted payment form" to charge our customers. A question came up on how we can populate the "payment form" automatically with information from one of our other system. We have no control over the hosed payment form, and we have to use IE. Is this possible at all? And if so, how can this be done?
If something is unclear, please let me know...
Assuming that you are essentially embedding the contents of a remote form in a frame/iframe, the you should be able to use some javascript to set values for the fields - field.value = "xxxx".
That solution of course depends on the form remaining the same - any changes to the remote form will require you to update your script.
If you are "handing off" to a remote site (redirect) that post's back to your site when payment is complete, then unless the remote site offers an API / a way of passing request parameters through, then you are going to be out of luck,
Unless your payment gateway allows you to pass through data in a set API (which lots do!), you'd need to take control (and responsibility) for your payment form.
I say responsibility because you would have to prove to your merchant account provider that everything is secure. This will probably incur some security testing fees too.
So check with your merchant gateway first. Lots of systems have the means to accept data from your site and their tech support will be able to give you a straight answer immediately. Otherwise you'd have to switch it over so you process all the data yourself which, just for making things easier, isn't worth it IMO.