What is the difference between put and flash.
\Session::flash('flash_message', ' Your article has been created! ');
\Session::put('flash_message', ' Your article has been created! ');
When should i use put and when I can use flash ?!
Sometimes you may wish to store items in the session only for the next request. You may do so using the flash method.
https://laravel.com/docs/5.4/session#flash-data
To store data in the session, you will typically use the put method.
https://laravel.com/docs/5.4/session#storing-data
The different is:
With put, you are basically storing the string "Your article has been created!" in the session and it will not be deleted any soon.
With flash, you are storing the value in the session and right after another request comes in (e.g: a page refresh) the session would be immediately gone and in that case, the same will also happen to the message (assuming you check before if Session::has).
So to answer your question, Session::put should be used if you want to store the message for a longer time (e.g: Webshop-Carts). In your case it seems like you just want to give a feedback to the user, so you should use \Session::flash('flash_message', ' Your article has been created! ');
Hope that give you a better understanding.
Related
I have some blog with some posts. Every page has a block "Read now" which contains post titles with count of readers at that moment (guests and auth users).The question is how to get these counters.
I am usinng laravel Echo with beyondcode/laravel-websockets.
Tryed to using presence channel, but it requires authorization.
You can try this method by SaeedPrez.
Alternatively, you could try going through Laravels Request like this:
Request::session()->all()
Try dumping and dying (dd() function) and see how you could parse the given response. As an idea maybe use a CRON and save the variables in cache.
I think you can try init Echo.listen() on public channel once user hit the post page. From that, you can build logic to see how many people are in that post.id page by temporarily store the count data somewhere in Redis or just in database the belong to that specific post. And remove the count when user leave the page by calling the Echo.leave().
There's no true solution yet since presence channel require authenticated user.
I remember in CodeIgniter there used to be a way, to force all flash data to the next request.
Is there such functionality in Laravel?
I have a route, that all it does is redirects, and if there's is any flash data, it 'disappears' there, and is not passed on to the request where it could actually be shown.
I know i can use redirect()->with('key', 'value'), but it would be nice to just have a way, to simply 're flash', any flash data, as it may or may not exist, and could be few different keys (that I might or might not know)
What you could do before your redirect() use:
$request->flash()
Your request will be stored inside the session
To retrieve flashed input from the previous request, use the old method on the Request instance. The old method will pull the previously flashed input data from the session:
$username = $request->old('username');
For more information:
https://laravel.com/docs/5.6/requests
and scroll down to Flashing Input To The Session
Hope this helps!
I find that some websites have sort of authentication even though no user is logged in. Taking plunker for example, even a non-logged in user can freeze a snippet such that other users cannot modify; whereas the user himself could always modify the snippet even though he opens the link in another browser tab.
My current solution is adding a type field (ie, anonym and normal) in the user model. Then, each time there is no normal user logged in, I systematically generate a unique random ID, register and login as an anonym user. It works, but the shortcoming is there are lots of anonym users in my database.
Does anyone have a better solution? Is there any "standard" way to realize this kind of hidden authentication?
I think method you are looking for is called session id. When you save as anonymous user web app creates a session with a session id which is used to identify the user by link. For example on plnkr it'll be something like https://plnkr.co/edit/session_id?p=catalogue where session_id is some sort of hash.
To freeze the snippet the session id is written into cookies with the flag, saying, for example, that the state is frozen. If you freeze it in Chrome and open in a Chrome's private window or in Firefox on the same computer, you wouldn't be able to unfreeze it. It'll behave the same way as for other users which have no cookies. In fact using session hash for cookies, rather than any user identification is better for security reasons.
Now this approach in a sense isn't any better, than creating anonymous users - you still have to save session records into the database to be able to open session context by link. In fact, it might happen to be simpler in your case to do exactly what you did if user is assumed to be present in lots of use cases and places in the code.
In many cases, however, separation of session from user makes lots of sense as it simplifies keeping session state after login or registration. Say some web stores would empty your basket after you register, causing quite a bit of frustration, especially if you put several small items into it which you now have to find again and put back. Those don't have sessions or don't use them correctly on registration or login.
Otherwise, as I wrote it's pretty much the same and you have to deal with many anonymous sessions which pollute the database unless you have some sort of wise retention policy, depending on you use case. Say, for example, a web site similar to plnkr.co which is used to share code snippets, and post them on sites such as stackoverflow should better keep those sessions while there are users accessing those say at least once a year. So sessions should have access date and policy would be that it's older than 1 year.
Hope it helps.
I have done similar using Local Storage. It allows you to store data on the browser. A user can then open tabs, close browser completely and reopen etc and the data is still there. It would then appear to be saved for them but actually it's just stored on their browser.
This wouldn't allow others to see what they have done though, so not sure if this is quite what you're after.
I wrapped them in functions in case I chose to change them out later, something like this
StoreLocalVariable: function (key, value) {
localStorage.setItem(key, value);
},
GetLocalVariable: function (key) {
return localStorage.getItem(key);
},
Some info including compatibility
https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API
I'm trying to create simple web-app using grails.
Now, I need create new session when user opens same page in different tabs to avoid displaying same data in all opened tabs.
is it possible to define that page was opened in new tab? if it possible how create new session in controller action?.
or maybe there is a way to get something like browser tab-id?
You seem to misunderstand how a session works and they are assigned.
A session is per browser (and domain/host).
So, even though you can create a new session in a controller action it won't help because that will become the session for all the tabs of the browser and the previous session(s) will be invalidated/abandoned.
There is no such thing as a browser tab id.
You'll need to address the root issue which is causing your data affinity to be based on a browser session. Make it based on something else. (Just a general suggestion since this isn't part of your questions and you haven't provided any details.)
Here is my thoughts on this.
What you are trying to accomplish may appear simple but you will need some mechanism to capture who each session be whether it be a spring security username or actual http session id and to then store with that what controller actions they have visited so far and to keep this consistently updated whilst checking it over and over again.
Something as simple as
[
['10001':[controller:'someController', 'someAction'],[controller:'someController1', 'someAction1'],
],
['10002':[controller:'someController', 'someAction'],[controller:'someController1', 'someAction1']
]
Where '10001' is your key of your map and is your session id then it contains a list of internal maps of places visited that you capture and try to work out if they been there already - basically the question here is....
Where is the AI to say if they have seen someAction1 they should see action2 and what happens when they seen action1 and action2 and so on an ever ending loop of and what next ?
Either way you could do all that as a session variable that contains a map like above - the issue you will hit will be concurrent map (where it gets updated and read at the same time).
So you will then need to look over and into using concurrent hashmaps to get around such issues.
Either way the problem with all of above is the consistent logic to figure out if they have seen all possible options then what next ?
I think you are far better off thinking of it from a different point of view as in base it on timestamp and move the query or whatever it is to randomly generate a different output based on that timestamp since that is always going to change regardless of the user
I am curious about the value of PHPSESSID because, I created a simple login-type web app. When I try to login with different accounts, the value of the PHPSESSID is not changing. I got curious if it does okay or not. Because I tried to login in youtube with different account too. But their SID's differ on each user.
My question is:
1) Is what happening on my web app okay ?
2) Is yes, how can I make a session ids per account/user ?
3) If no, how can I fix it ?
I would really appreciate your suggestions.
It partly depends on exactly how you implemented "login." One way to do it is simply to change the user-identity (which, by definition, is part of the data that is stored in the session), while keeping the same session.
Another equally-valid way to do it is to first update the existing session (to show that the user, in that session, is now "logged off") (maybe...), and then to coin a completely new session-id, thus starting an entirely new session, in which you now "log on."
One advantage of the second approach ... and probably the reason why so many sites do it this way ... has to do with the possibility that the user might wish to open a new browser-window, and to log-in to the application a second time, intending to keep both logins alive at the same time. If the session-id token is part of the URL, or maybe is part of a hidden form or what-have-you, such that both session-id's can be retained independently, it becomes possible for the user to do what he has done without conflict. Two parallel sessions exist. In one, he is logged on as "joe," and in the second, he is logged on as "jeff." And so on. One set of browser-windows (somehow ...) carries the "jeff session" token; others carry the "joe session" token.
Fundamentally, a "session" is just a pool of server-side values, identified by the (PHPSESSID ...) token furnished each time by the client. Exactly how you choose to manage it, is at your discretion. It's a design-decision with no "correct" approach.