Is there a way to distinguish access through external link (e.g. from history, or from other site) or access by link from other page of the same app in beforeModel handler?
Here is my case:
If user accesses my app by direct link and requests route requiring authenticated user, I make a transition to index route and show popup with an authorization form.
If user is already on my site and trying to access the requested route requiring authenticated user, I abort transition and show the popup on a previous page.
I have no separate page for authentication.
My current work around is to check some strange private property called sequence of transition object which has been passed to beforeModel handler, if transition.sequence === 0, then user came from "outside", otherwise user follow by link "inside" my app.
I think this is a bad way to achieve the goal, core developers can remove sequence property any time.
So, is there any clean way to distinguish whether current route was requested from "outside" or "inside" of my app?
I'll appreciate any help, thanks!
P.S. EmberJS v1.10.0
P.S.S. Sorry for my English
If you want to avoid using an internal call you could keep track of the history in the application route something like this Implementing a "conditional" back button in ember.js
But in your router would probably be better since controllers are going away soonish.
You could probably use http://emberjs.com/api/classes/Ember.Route.html#event_didTransition
UPDATE after chatting
Logic for counting, aborting, etc transitions can be done in the willTransition action in application route http://emberjs.com/guides/routing/preventing-and-retrying-transitions/
Related
I need to track unregistered users in my Django website. This is for conversion optimization purposes (e.g. registration funnel, etc).
A method I've used so far is using IP address as a proxy for user_id. For various well-known reasons, this has led to fudged/unreliable results.
Can I sufficiently solve my problem via setting a session variable at server-side? An illustrative example would be great.
For example, currently I have a couple of ways in my head. One is doing request.session["temp_id"] = random.randint(1,1000000), and then tracking based on temp_id.
Another is setting a session variable every time an unauthorized user hits my web app's landing page, like so:
if not request.session.exists(request.session.session_key):
request.session.create()
From here on, I'll simply track them via request.session.session_key. Would this be a sound strategy? What major edge-cases (if any) do I need to be aware of?
Cookies are the simplest approach, but take into consideration that some users can have cookies turned off in their browsers.
So for those users you can use javascript local storage to set some data. This information will get deleted once you close the browser, but it's ok for funneling purposes. Still others can have javascript turned off.
Another approach would be to put custom data(key) in every link of the page when generating the template. in other words you would have the session_id stored in html page and send through url parameters at click. Something similar happens with csrf token. Look into that.
I'm having a weird issue in ember js with sending actions from one route/controller to another route. The action never hits the other route's action handler. I can send actions from controller to controller, from same controller to same route, but not an additional hop from one controller/route to another route handler.
Ultimately what I'm trying to achieve is sending an action from one route users.new to another route, users.login. The action isn't handled in users.login's controller so I was assuming that it would bubble to the users.login route action handler.
Any help is very much appreciated!
Actions bubble to controllers and then to its route and then the ancestors of that route. They are not used for communication across/between routes.
The question is, what do want the action to do? It sounds quite a bit like you really want to transition to a route, instead of sending an action to it or its controller. If you want to pass parameters along with the transition, you can do so using query parameters.
If you could provide more details or existing code, we might be able to give you some specific code fragments.
If for some reason you are real sure you want to communicate between routes and controllers, you can use Ember events. You send them using this.trigger('event') and listen for them using object.on('event', handler). However, I doubt if you need this for the problem you are trying to solve.
I have no idea how session services are supposed to address this problem. Normally, a session service is how you would keep track of session (user) information in a way accessible to very controller/route etc.
Sending actions from peer routes does not work. The solution is to create a session service.
I have a customize request from my client in sitecore mobile module.
I want to be on full view site from my mobile on Career page, i am able to do it but any of the link inside career page with having mobile layout in presentation detail is taking that page again to mobile device.
Can we make any customization that maintain the device in cookies so that it keep user on full view site after coming to career page.
Is there any setting we can do in pipeline or session. I just want to be throughout in full view site after coming on career page and no going back to mobile layout. Kindly suggest.
Yes, you can do exactly that. You'd need to update the rule to detect the various devices (which I'm guessing you already have). You can then create a custom condition to check if cookies have been set for the full site(does not need to be a cookie of course, but that'd be the easiest way).
You can find the existing Conditions and Actions here in the path /sitecore/system/Settings/Rules.
To create custom conditions and actions, please read the following article on SitecoreInsight.com
After creating your custom condition, go into your device item again and update the Rule there to only switch to that device when that cookie has not been set.
[edit]
Come to think about it, it might be possible to have your 'go to full site' link appended with a querystring sc_device={GUID of device}. I'm not sure what would take precedence here, the 51degrees rules or Sitecore's cookies... Worth a try though :-)
What's the proper way to end an Ember application?
In my application, I have a logout button. When pressed, the app sends a message to the server, which terminates the user session and does some cleanup. On the client side, I currently just transition to the login route, which doesn't really terminate the application since artifacts from the prior login remains. Hitting the refresh button manually would do it. Does Ember provide a function to programmatically refresh a page? Is there a more elegant way of doing this than a refresh?
There's a couple of things you'd need to do.
To reset Ember itself you can just use App.reset();
Reset any client side record management software (this is different for Ember Model/Ember Data).
Ember doesn't provide a way to programmatically refresh a page, since you can just use window.location.reload().
I've inherited some Ember.js code that is used in part to maintain an online shopping cart. The problem is that the current code base does not maintain the state of shopping cart content anywhere but in the model, and so when the user reloads the page (via the browser's reload function) anything that was already in the cart is lost and its value resets.
For better or worse this application was written as a thick-client with almost nothing but user authentication details and reference data stored on the backend.
My question is: is this the normal approach for Ember applications? And if so, what is Ember's best practice for maintaining session state across browser actions that don't directly interface with Ember's router? I figured a short-term band-aid might be to stuff the cart contents into a cookie on the client side, but there seems to be little in the way of cookie management in Ember.js, and it also seems somewhat inconsistent in spirit.
Thanks.