I am new to rails, cucumber and rspec. To help learn all three, I've started building a realistic application that requires login.
I would appreciate a little guidance as to where to start and confirmation I am on the right path.
I started with 2 features files. However, I have stopped at this stage as I'm wondering whether the 'login' feature (although a core aspect of the app as they can't do anything without being logged in) should come after the other assets and models, such as the things they manage when they are logged in.
So, which would come first? Features for the login or features for the models they manage?
example feature files:
Feature: User loads application
As a user
I want be able to load the application
So that I can manage my files
Scenario: Load application
Given I am not yet using the application
When I visit the application
Then I should see "Welcome to app"
login feature file:
Feature: User logs in
As a user
I want be able to login
So that I can manage my private files
Scenario: Successful login
Given the user "Username" has an account
When they login
Then they should see "You have logged in successfully"
Should I have started with a feature that they will actually use as the point of the app?
The order in which you implement features is a business decision. Whether you start with the login process or another feature depends on the business value each feature carries.
To help you find out where to start, you'll need to ask questions to the stakeholders. Here are a few examples:
Could we build feature A without user authentication?
Do we absolutely need user authentication at this point?
Let's consider we have resources to build only one single feature, what would be the most valuable one right now: login or feature A?
Building feature A before authentication can be a good strategy, as you'll be able to expose the feature to test users and improve on it earlier. Or, it could make no sense at all on your specific project and you'd want authentication to be ready before anything else.
Now, to comment on your particular scenarios, the style your using is pretty good.
I have the feeling (I might be wron) the user loads application feature is not really useful though. As a user, do you care about a "welcome to app" message? This scenario looks like a pre-functional setup test, something you'd like to have as a developer to kick off the development process. But it does not seem (again I might be wrong) to tell anything useful about the behaviour of the application.
This could be encapsulated behind a Cucumber feature describing some real expected behaviour of your systm (like the login process or adding items to a cart or reading blog posts, whatever is relevant to your domain).
Related
I recently asked this question and user's #DalmTo and #Sergio NH they gave me an exhaustive answer for which I thank them very much.
Moving forward to question, we started publishing the application, and its verification was not required, since no scope was added (here it is a little unclear why the requests worked in an application with a test mode in which these scope were not added (google drive, google sheet and google ads)).
However, this time the application in the "In Production" mode began to give us an "Unverified app screen" (see Unverified app screen). We decided that we still need to add scope to the list, and, of course, that the scope list (their list is described above) requires verification by Google.
We started filling in the necessary fields, while studying the Google documentation at the same time, and came across the following information (see block Verification process -> What are the requirements for verification?):
Apps not applicable for verification
Apps for internal use only
(single domain use) Apps for personal use only Apps that are Gmail
SMTP plugins for WordPress Apps that are in development or
staging/testing
Apps for personal use only
And this is just our case: we have already received permission from Google Ads and are just generating simple reports that we want to integrate with Google Sheet. I.e., this is an elementary script that works within this account (however, we still need to request the first concert screen, even for this developer account) and cannot be distributed to any other accounts.
But when adding our scope, Google requires us to pass verification, forcing us to fill in the required fields, in the form of domains and their verification via the Search Console (we have already done this and this stage does not cause difficulties) and links to Youtube videos - where we must show how scope is used.
And just this stage is not clear. We do not allow other people's accounts to connect to this application, and the software does not have any interface, it is just a script that receives data from Google Ads and saves it to Google Sheet (creating a file via Google Drive). We have described all this in the scope usage description field. But the link to the Youtube video is require field, and we sincerely do not understand why (considering our case) we should record something, and most importantly, what exactly we should record in this case. If the documentation itself says that in our case we do not even need a verification.
Maybe we did not understand something and now we are doing it wrong? We will be glad to receive any tips from experts working with Google Cloud Console and apologize in advance for broken English.
We also apologize in advance to the StackOverflow community that we have to publish such elementary (which we are absolutely sure of from our side) questions here. We come here from Google Cloud Console - > Support - > Community support, and we must first try to publish posts in the Google Groups specified there, but they simply do not answer us, apparently considering our questions too elementary and not worthy of attention (however, these same questions in Google Groups are moderated) (for example, the previous question). And we are no longer able to contact any other support. Once again, we apologize for having to ask about this here.
It is true that if your app is a single use app then you do not need to be verified.
However if you don't get your app verified then there will be some restrictions.
you will see the unverified app screen
your refresh tokens will probably only be good for two weeks.
In the case of the YouTube api uploaded videos will be suck private.
If you can live with those points then you don't need to verify your app and you can continue as is.
If on the other hand you don't want to see the unverified app screen and you want a refresh token that will last longer then two weeks. You will need to verify your app. Yes, Even if your app is a console application running as a job some where you still show the consent screen. This is the YouTube video you will need to show Google. Show the consent screen popping up show the URL bar and then show your script running. You also need to set up the homepage and privacy policy screens. Yes i 100% agree with you that this is silly.
When you go though the process. Explain to google that this is a single use script running as a job some where.
Unfortunately when Google changed it so that Refresh tokens expire for unverified apps they pretty much tied the hands of all developers who are running such single user scripts. We now have to get our apps verified if we don't want to have to request a new refresh token every two weeks.
If your program needs to access the requested scopes of the Google account privacy, even though the user is yourself, you also need to provide a youtube video to demonstrate how you use this program. The auditor cannot guarantee whether you will make this program public.
Searching for oauth2 stuff seems to bring up dozens of Q&A's on client-side integration (like how to authorize with google/facebook apis) or using existing providers (like solutions for popular frameworks), but I am having a hard time finding info on building a solution on top of a pre-existing user/pw db.
Can someone please outline the bullet points of exactly what it needs to do in order to extend the existing system to provide oauth2 authorization? i.e. the existing system already provides registration, password recovery, login, forgot email - all that stuff without a framework (golang and password is hashed with first x bytes as salt, in case it matters). I don't want to toss it all out in place of an out-of-the-box solution which covers all that + oauth2. I want to add oauth2 by hand (or using minimal golang libraries) on top of the existing system.
I'm currently trying to reverse engineer and look at existing code, but it's a bit confusing and when it comes to authorization/security stuff I don't want to be making guesses, even educated ones. Could look at the spec too but I don't really need cover everything in there, just the bare minimum to let another site authenticate (by calling a "getprofile" API after authorized, maybe I'll make that compliant with openid connect but never mind that for now unless there's no increase in steps).
Sample code or libraries if any are preferred in go-lang since that's what I'm building in, but pseudo-code or vanilla code in other languages is fine too
Is there a recommended "Polymer way" to do user authentication?
This question includes both the technical pieces AND the UX.
A soup-to-nuts example (and/or tutorial) of a UX for doing user auth would be fantastic.
Note: The Polymer Starter Kit does not contain any authentication UX examples.
In this question...
"UX" means:
The COMPLETE "user-experience" involved in signing up for a new account, logging in and handling forgotten user id or password. For example, a typical landing page for a typical web app will usually have some buttons in the upper right corner for signing up for a new account and logging in. What happens when someone clicks those buttons and how to handle the entire flow would be a very useful example for Polymer developers given that functionality is necessary for most modern web apps. I would love to not have to create my own amateurish "home-brew" concoction from scratch for a solution but, instead, to have something relatively professional and generic I can "plug-n-play" into my app and modify only if/when necessary.
You need to build a custom element with all the relevant styles, templates and scripts to express the UX.
I am trying to use BetterAuthorizationSample rather then go the so called "malicious" way of using setuid in order to get root privileges.
Currently I am using AuthorizationCreate(); with BLAuthentication to have root access to changing some files, but I am somewhat irritated by the fact that I have to constantly enter my password in every time the app launches.
So I came across Apple's method of a HelperTool, and I just can't figure it out.
I've been working with Cocoa for a couple months now, but this is just out of my reach, yet I still need it. How would I implement this tool to do simple root-privileged tasks?
Is there a simpler way to use the concept of a HelperTool, so that my users can just enter their password once and it would grant root-privileges forever?
The "modern" way to do a helper tool on Mac OS X is to ship it as part of your app, and use the ServiceManagement framework to deploy it. Your users enter their password once, when deploying the tool. That installs it as a launchd job; from then on you use any launchd on-demand mechanism to launch the helper and get it to do work for you.
Notice that the blog post linked above recommends that you protect subsequent invocations of the helper with an Authorization Services escalation, to avoid having an arbitrary privilege escalation that anyone can use. This seems like it somewhat impacts the "users can just enter their password once" benefit, although you can use AuthorizationRightSet() to create your app's authorization token in the policy database, so you can actually define whether users need to present passwords on first deployment.
The sample code from that post is on GitHub, and demonstrates using ServiceManagement to deploy the helper tool and Authorization Services to control access to it.
Alright. So I am new, I know my way around html pretty well, and have gotten by for a while now doing so. But today I am presented with a seemingly simple issue.
My client needs the ability for users to create their own LOGIN/PASSWORD, my client wants to be able to MANUALLY approve visitors. And he want to be able to track how many times they login.
The login section will just be about 4 pages of PDF file downloads.
I cant imagine this is the hardest thing in the world, I just have no clue where to even start. Perhaps there is a code already written, as things like this are done every day using forum technologies...
Please help!
It may also help to mention that I am using Dreamweaver cs4 on a MAC
I'd check out Ruby on Rails if I were you. It's pretty easy to get something quick up with it that you can have users create accounts with that send e-mails to the client with approve/reject options, and be able to track downloads and users via MySQL or other databases.
I've found Agile Development with Rails to be a great source of info on how to do stuff like this (they do an online bookstore as the book's example) and with a little modification I think it should work for what you say you want to do (and the book is pretty cheap as far as programming books go).
If you want just really basic static login features without lots of coding, you can start with Password protecting your pages with htaccess. You can password protect directories like this without any effort at all. This way, you can be sure that your login routine is secure.
Then, you can continue with advanced features like account administration and login statistics. These will require some programming skills.
Tracking count of user logins should be easy too. You can put simple PHP code to the source of protected pages that will save the info about login to the database. This will require you to study some basics of databases. You can use plaintext files which is not as clean but much easier and it will allow you to export info for your client more easily.
If you want to do it profesionally, you should invest in learning about web development or hire someone to do it for you. These tasks might not be trivial.
Have you worked with PHP, ASP.Net or some other web language yet? What you're trying to isn't too difficult in the grand scheme of things but it may be somewhat challenging if you haven't programmed before and/or haven't had any experience with web development.
(P.s. Alter your question as a response and comment on my answer when you're finished.)
As you are looking into Ruby on Rails, take a look at bort which is a RoR app skeletton with RESTful authentication included, it should help (Chris Bunch answered on the general RoR question).
There is also this bort fork. There is also Authlogic which may be easier to work with.
Have a look at the ASP.net Membership provider and also the login controls which provides the UI for the login as well as registration screens out of the box.
Here is a Multipart Series on ASP.NET's Membership, Roles, and Profile
If this is too complex than probably you can also design you application from scratch using ASP.net. If you don't know asp.net than the best place to start is www.asp.net it has several videos and tutorials which would help you get going soon.