Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Anyone can explain about this question ?
If the actors who will be using the applications are not determined before
the creation of application, which of the following will happen? Select any
two choices.
a. We will be unable to create reports and dashboards
b. Unauthorized users can access sensitive data
c. There will be no room for scaling the application to large users
Thanks,
I don't think this question is one StackOverflows' rules would consider good. Did you copy it from some certification exam maybe? ;) It's not exactly programming problem-related.
I'll flag it for mods but also try to attack it :P
An app is not much in SF world. Set of (default) tabs, that's it. If an user has no access to app that mentions tab XYZ it doesn't mean he can't access the tab from "all tabs" menu. The more important thing is the security setting on the object that says:
tab hidden - meaning user with this profile is not even aware such object exists in the database, even if he has "Read" permission ticked
default off - accessible in "all tabs" menu
default on - visible by default in given app if said app is selected
a. We will be unable to create reports and dashboards
No. Sysadmin will be able to see all data (and thus create reports) even if none of the apps includes this tab. What they talk about in this answer is controlled by object's "allow reports" checkbox (and if it's not ticked even being a sysadmin cannot help you). Normal users won't be able to make reports/run exisitng ones on given objects without having at least "Default off" + "Read" permission on the object in their Profiles.
b. Unauthorized users can access sensitive data
Yes? I can imagine this happening - you don't know which Profiles should access given object, you give Read access to all users, funny things happen. But then - by default nobody can see the data except people with "View all/Modify all" (like SysAdmins) so it's a bit weird answer. You'd have to explicitly go to each Profile and enable access...
c. There will be no room for scaling the application to large users
I don't understand this answer so I'm going to go with "no, bullshit" :D You can always grant access to given app (or object) per profile or even permission set if you have to, I don't see how this can become an issue...
d.
I'm missing 1 more answer, are you sure you copied complete question? I've never seen a SF exam question with less than 4 answers...
Disclaimer: I've never seen similar question on my exam or any practice exams. I've passed 201, 401 and 501 tests.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We're creating a new web app based in Node. As many apps do, we would like to restrict the number of users who sign up, so we can test and scale up smoothly. So, people would sign up (with an email address), and then when a batch of users are released (either manually or automatically), that batch would receive an email that would allow them to sign up.
I've seen this process a number of times on the user side, but have never been involved with building a beta queue system, so I'm not sure the best way to approach this from a architecture / code perspective. Some specific questions might be:
What would be the flow for signup from a Node perspective?
What might be the underlying data model?
For "time-released" or batch releases of users, what might be the best way to manage that or trigger it?
Are there are node modules that might help with this?
Any help appreciated.
I implemented something like this in a .Net / SQL Server setup.
Basically, the user table had a flag indicating that that user was a beta user and allowed access.
Then I modified the user authentication module to return a different error message indicating that the were signed up but they couldn't access the application yet. This would only show if they successfully authenticated like normal. You could also send them to a different landing page so it doesn't look like they used the wrong credentials.
Next you can provide an admin interface to kick off a script to set the beta flag on a batch of users. This should also trigger some type of notification to let the user know they have access.
For time released options, you could have something else trigger the batch script to set the flags, or have a monitor service that finds any users without access that signed up over X days ago.
I think a lot of this would need to be customized based on your application and when you want to release beta users. There are also some services out there that allow single sign-on and gather analytics about your beta users if you want to see more information without having to roll your own.
Hope this helps. It would be nice to see an actual module you could drop in and configure with your specific database, user model, and authentication / signup process.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I haven't visited haskell.org for a while. When I did the other day, I discovered that a company called FPComplete have started offering a number of rather interesting Haskell services. However, there doesn't seem to be much documentation anywhere, and I'm a little bit confused...
If you go in through the "front door", you're required to create a user account before you can do anything. But sometimes you can click on example code and instantly start editing and running it - seemingly without requiring any kind of account. So is an account required or not? Is there some way I can just try stuff out without going to all the trouble of setting up an account?
Also, if I "start a project", is it public by default, or is it private? If I close my browser window, does it go away? Or does it stay in existence forever? If I don't actually want the project anymore, can I delete it somehow?
I'm also a little confused as to the difference between "FP Haskell Center" and "School of Haskell"...
School of Haskell is a community-driven set of Haskell tutorials and articles with "live" code snippets embedded into them.
FP Haskell Center is a cloud IDE for Haskell with full-featured editor, git integration and so on.
After registration you can create both tutorials for School of Haskell and your own projects, which can be private. IDE projects are persistent, until you manually delete them.
What makes you think you are required to create an account if you go through the front door? Yes, creating an account is the biggest thing on the page, but if you just ignore than and go into the alternatives in the lower half, you can create projects, etc, without going through the process of creating an account.
That will automatically create a temporary account. You can turn it into a permanent account by going through the registration process. That requires validating an email address. A google+ or Persona login will do, or you can go through the "here's my address - get email - click validation link" dance.
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 5 years ago.
Improve this question
I have an issue at work where we have just started using scrum as a development team. I am having some trouble with the user stories we are provided with in that they don't seem to fit what my interpretation of what a user story is.
Here is an actual example of the user stories we have been given for this sprint:
As a website user I want to have a registration page so that I can register and supply my details.
As a merchant user I want have validation on the registration form so that I provide the correct information. (This relates to Form Validation)
As a merchant user I want support when registering so that any questions that i have about the required details are answered. (This relates to Tool tips on the form)
The first one in my mind is the user story. The second two seem to be traditional requirements of the first user story and I think they should probably be acceptance criteria of the first user story.
The other confusion I have is in the last sprint we had:
As a user I want to be able to login to the website.
As a user I want to be able to login to the website with a username.
The Product Owner says this is two different user stories which need to be tested separately.
My issue is that in creating test cases and acceptance criteria for the second two - it is difficult as they are so specific and so related to the first user story. It seems that we are just putting up traditional requirements on a card up on a board and calling it something else. I mainly just want to know if I am wrong about this / why?
It just seems to me that we are currently just letting the users create whatever they want as a user story and not helping them filter them from requirements into proper user stories. I am told we need to keep them all separate for reporting so we can keep a log of everything the user requests.
User stories focus on customer value. ... The actual work being done is fleshed
out via collaboration revolving around the user story as system
development progresses. ... In order to limit scope, user stories have
collaboratively developed acceptance criteria which define when the
user story meets the stakeholder’s expectations. Test cases are often
developed as code (with test driven development) or documented as the
code is developed.
[Emphasis mine.]
As a user I want to be able to login to the website.
As a user I want to be able to login to the website with a username.
Since neither provides any customer value, neither are user stories.
You use application software to manage information, make decisions and (ultimately) take an action. If the user story doesn't provide some hint as to what information, decision or action gets taken, there's no customer value, it's just technical folderol -- implementation details that a customer has to endure to get to the interesting part of the application.
Login, specifically, has zero customer value. It's a roadblock that IT erects between customers and the valuable information they need to make decisions and take actions. It's a security mechanism, and most people do not actually like security. Security is imposed on customer by IT. The most popular password (IIRC) is "aaaaaaaa". Why? Customers don't like security.
Detailed, microscopic login user stories may be a symptom of failing to see the real value to the customer.
It just seems to me that we are currently just letting the users create whatever they want as a user story
Good.
I am told we need to keep them all separate for reporting so we can keep a log of everything the user requests.
Not a bad plan, really.
The issue is to separate "crap the user happened to say" from "stuff that makes sense that we can build". It's very, very important to allow the users to say any crap they want to say. It's a good thing to let them ramble.
Periodically (before each sprint) you will prioritize crap the user said into a few things that (1) you might be able to build during the sprint, and (2) create the most significant and dramatic user value you can possibly create. Some stories will get ignored. Some will be low priority. Some will be combined and some will be split. Some things the user said will be contradictory. Some will be outright lies. Some will be incomplete. It's all good. It's just crap the user happened to say. Not divine directives from the mouths of the gods directly to you.
This revised set of user stories drives the sprint. Now you start collaborating with the users to get the details, write test cases, define acceptance, etc., etc.
As you're sprinting toward delivery, the users can continue to say crap that will get appended to the backlog of unimplemented user stories. It's very, very important to allow the users to say any crap they want to say. It's a good thing to let them ramble.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
From what I understand, you have to enter in all of your usernames and passwords into Mint, so I assume they are actually logging into your bank account and scraping the resulting screen to put this data into a form that Mint and others use.
How do they actually simulate the keypresses and mouse clicks? I assume banks don't like it when they do this - how do their scrapers avoid detection?
I'm pretty sure they don't simulate clicks, etc. In the end, any data that ends up on a user's page is transmitted in a response to a request. If you can figure out how to construct a valid request and then how to parse the response, you'll have the data you want.
As far as I could gather after using Yodlee for quite a while, they deal with sites in two major ways: the sites they have official agreements to work with and the sites they don't have official agreements with. For the first category of sites they, most often, have agreed upon APIs for getting the data. For the sites in the second category they reverse-engineer layer 7 communication protocols and data structures (a.k.a. screen/html scraping).
The way I understand it, Yodlee uses the OFX specification to access banks' financial information.
http://www.ofx.net/
For the banks that don't implement OFX, they use custom screen scrapers, which must constantly be updated when banks change the information that's displayed on their site.
I don't know Yodlee so i simply assume it's like "sofortüberweisung.de" where you give a 3rd party your bank login data (and depending on what you do even a valid TAN) and thus trust them not to abuse it and additionally break your bank's security regulations ("NEVER GIVE YOUR YOUR PIN/TAN").
They most likely simulate what a browser would do. As web-based banking interfaces are usually just HTML/JavaScript everyone can look at the client-side code and do whatever it does with a custom program. Since those actions are not done in a malicious way, actions which require e.g. a TAN or a CAPTCHA to be solved can be simply forwarded to the legit user who will then enter the necessary TAN or solve the CAPTCHA.
Nonetheless to say, it is really bad to use services like that. While they most likely won't do anything bad you cannot know it for sure. And your bank is damn right if they don't refund you anything if you ever get scammed by such a service.
Another solution which would be perfectly safe (as long as you are not concerned about a 3rd party knowing about your financial status etc.) would be the yodlee company making contracts with major banks allowing them to access your data after you've authorized it through some way (you can already do that on pages like Twitter - I'd never do that for bankign though but technically it wouldn't be hard to realize something like that). That would be clean and secure as it would not involve "screen-scraping" or customers entering their banking login data anywhere but on their bank's website. But I believe no bank does something like that and in my opinion that's good as there are way too many people out there who are far too trustworthy and we all know how many information they give out on Facebook & Co. Now imagine a facebook<->bank integration... M.Zuck.'s wet dreams which hopefully never become true... And even if it's not Facebook.. There'll always be companies who want people's personal data and enough people giving them out; especially if it's easy and looks secure ("I have to confirm it on MY BANK's page. so it MUST be safe - it's supported by MY BANK").
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm a full time software developer, but on the side I'm teaching a university course on web services. I'm going over security right now and was wondering if any of you all have had any security breaches that you could tell about (details obscured as needed) that I could share with my students. Real life stories are a lot more meaningful than made up scenarios...
Here is a story from me:
I once was customer of an online audiobook store. Beside authenticating myself with username and password, I also needed my browser to accept cookies. This wasn’t unusual. The cookie is probably needed for storing the session ID.
But I got confused since the session ID was also transmitted in the URL and I didn’t saw a reason for why there was a need for cookies. So I took a look into my cookie jar to see what oh so important information have to be stored in cookies.
Beside a cookie for the session ID there was another cookie named customer_id that obviously was designated to identify me by my customer number. I thought: “Come on, no one can be this stupid!” I altered the value for fun by changing one digit of the number (e.g. from 12345 to 12346) to see what happens.
Now guess what: I now was logged in as a different user without any further request for authentication just by changing the cookie! The customer_id cookie value was abviously not just for identification (Who am I?) but also for authentication (Am I really the one who I pretend to be?)!
The moral of this story: Always separate identification from authentication.
This may not be what you had in mind, as there was no information compromised, but it still very much a web security issue.
http://www.crime-research.org/library/grcdos.pdf
That is the classic story of how internet security guru, Steve Gibson's, site was attacked by a botnet. It is a very interesting story and would certainly keep the class engaged. I know this story got me more interested in web security.
I could not find the original post of that pdf on Steve Gibson's site (grc.com), but I had a copy on my computer and was able to search for it and found it at the given location.
I also recommend going to grc.com and listening to the "Security Now!" podcasts:
http://www.grc.com/securitynow.htm
You will almost surely hear some stories in some of those podcasts.
Hope this helps!
The European Identity Conference (EIC 2009) in Munich will be featuring a case study on SOA security that will have the information you seek.