Both Derick Bailey and David Sulc are very conclusive at the time to have the Landing page and auth logic (+ login/signup forms) separed from the actual Marionette app. However, I haven't been able to find any example nor explanation of how should this be handled and thus, I have few doubts:
CHANGING THE INDEX.HTML
The index.html won't be loading the Marionette app anymore. This means that when loading example.com we will end up in a simple landing page even if the user is authenticated (localStorage has his token credentials stored). I understand that this simple landing should somehow handle that if the user has stored credentials, the user should be immediately redirected to a app.html that will actually load the Marionette app, with the users account and the initially accessed route. In other words:
The url fragment is stored.
Check if user is logged in
If the user is logged in, then load app.html which will load the app (how to load the app for a certain route?)
If the user is not logged in, then do nothing
LOGGING IN
In the case the user is not logged in and logs in. Independently of if index.html has the login form or we have redirected the user to login.html, our auth logic has to be independant of the app. This means login.html has to include a .js that will make an ajax call against out API.
User enters credentials
AJAX call to check credentials
If API returns token, then store credentials in localStorage and load app.html (which will load the marionette app)
SIGNING UP
The user signs up at /signup signup.html or index.html if this includes a sign up form. Whichever HTML is loaded, it must include the necessary js logic to make an ajax call to the API for a new user.
User enters new account data
Our independant js makes an ajax call to the API
If creation successful we store the data to localStorage and load app.html (which loads the app)
If not, we show errors
And you'll say I'm missing the question. My question is, are these workflows correct?
Which workflow do you normally use?
How do you structure this code inside the marionette app project folder?
If you know of any simple examples on github on how to approach this I'd be very happy to learn about them!
Well, in case someone stumbles upon this question, I finally decided to have the landing/auth logic inside the Marionette app. This way I keep my backend to be only an API REST, and I don't need of any further backend to serve me more pages.
Related
I searched a lot in here, and i couldnt find an answer to the questions I ask myself. Here is the thing :
On one side , I want to have a static landing page (with login/sign up form ), and on the other side, I have an angular app that handles all the things related to the authenticated user. It's like that because my app is kind of "private", so users that cant register or login do not have to load the entire angular app and can't go further than the landing.
On the landing page, the login request hits on my API, and with the given credentials I store the user access token in the local storage, which allows him to do all the future requests inside the angular app.
What I want to do is to have the same URL for both the landing and the angular app. Let's say the base url is www.myproject.com, when I go to this url, depending on if i'm logged or not, i want to be redirected to the landing page or the angular app. It's also based on a "Remember me" checkbox.
So how do I do to share www.myproject.com between the landing and the angular app, depending on the user state ( logged or not ) ? Is it some kind of server routing ? Or can I achieved this with angular ui-router ?
It's only a matter of fanciness, i could also have urls like www.myproject.com for the landing, and www.myproject.com/app for the angular app, but the real problem here is how to do the logged/not logged based routing. If it simpler to explain with two differents urls, I'm interested too.
Thank you for your answers, i feel really lost here !
EDIT
Since ALL the requests inside the angular app need the access token, what if I catch 401 error that i might get from oAuth when entering the angular app, with an http interceptor ? Could I use this to redirect to my external landing page file ?
I don't really need the share of the root url between the landing and the app, all I want to know is : is catching 401 code a good way to redirect to the landing/login page ?
I wanted to know how people would go about having a sign in page for an Angular app that was completely separate from the app and once authenticated would be passed through into the main angular app. So something like a Signin.html page that once authenticated passed onto index.html.
The thing I can't get my head around is having the moules loaded into the main app on signin.html and how you then handle moving to index.html that has its own modules and whether you can pass user information between the modules on signin -> index.html.
The way my app currently works is a modal for sign in that is part of the main ng-app and simply has the app behind it.
One approach you may want to explore is, provided both pages are from the same origin (ex www.myapp.com/app) you may be able to store authenticated user information in local storage. Upon succesfull authentication, your signup page will save the user information in local storage using $localStorage and will direct the call to index.html. Your index will not have access to whatever stored by signup.html via local storage.
Curious as to how people usually handle this. My strategy is to have an authorized root route and unauthorized root route.
The authorized users get sent directly to my marionette.js single page application and unauthroized users get sent into a standard rails landing page with the option to login or register.
It seems you could combine these all into your single page application. You could show/hide ui elements based on a class you attach to elements based on the authorization needed to see them (registered, admin, moderator, etc). You could also add some kind of "before_filter" to your router's that can check whether or not the user can access this route given their role.
I'm not sure exactly how you would handle login / registration in this case. You could setup your own api routes that get POST'd to which hand-off the work to devise?
Thoughts? Strategies? What seems best practice here?
I find it painful and unnecessary to try and make Backbone/Marionette handle the authentication and re-loading of the authorized site stuff. Once they log in, redirect them to a different URL that the server handles, and have the server send down all the stuff that they need, as an authenticated user.
In my work with a Javascript single page application, i have recently run into a problem.
The whole idea behind this project, is to avoid page reload. When the user comes to my application they won't need to make any reloads. This is done with jQuery and Backbone.js and PHP as service.
I have this static index.html file, where i hide my login container and application container. Then i show the login container, if the user is not recognize by my application, and if they have auth i show the application.
if auth:
application.show()
elif not auth:
login.show() // like Gmail or Facebook etc.: Information + login-form
I wan't to show users who aren't authenticated, both login-form and general info. Very important is also that the site can be found by robots as Google etc.
Can this only be done with 2 different files, giving me reload? A site.com and login.site.com. That solution irritates me, because my login, as it is by now, is quite instant.
Not sure I get the question completely but if you want to check if a user in authenticated, try to do an ajax call. If it fails with "401 unauthorized" the user needs to login...
You can achieve what you want by using ajax calls to authenticate (Although this is not a recommended approach, and people usually prefer the two page solution you have outlined).
What you can do, is have very skinny controllers that just exist to provide data to rich client UI.
Your gateway controller(A separate controller, with no model that acts as an entry point in the application) will just render the basic application structure to the client (without any user specific data, you dont know if the user is logged in, you dont need to know at this point). Then the client will query the UserController for identity of currently logged in user, if user is logged in server returns a json response containing information related to user and if not, server returns a response saying that user is not logged in. Then you can fetch a partial for the login form and then submit it again through ajax. As you see, creating the UI once and communicating with the server with lightweight ajax calls can solve your issue easily.
I am working on creating an iphone application which logins to we website and retrieves a table, and displays the content within the app. To view the table a Login is required. It seems the site is using Form-Baseds Authentication. WebSite's Login Screen
So How do I pass the login ID and pass from xcode to the to the site and retain the information so the user only needs to login once.
to remember the login credentials, the easiest way is to put them into a NSDictionary and write that to the application bundle, then read it later, when needed. Remember to give the users a chance to change their login credentials later on and at least think about encrypting the data.
As to the form-based login, the way to go would be to create a NSURLRequest to the login forms URL, if it is GET-based, simply do it like url.somewhere/form?user=foo&pass=bar, if it is POST-based, alter the created request and include the information needed in the POST-field.