each time I try to configure a session in HermesJMS it does not appear in the session window. I can still see it in the session drop down if I select to create a new session however it gets dropped from the main view where I want to view it in order to be able to create topics, etc. any ideas. I've attached a screen shot so that you can see what I mean
the below is what I have created:
the below is what I can see - which is only file
Its unclear where the other ones are?!!
Found the issue it is related to part of the config not being required - it doesn't error it just doesn't show the session as being viewable. which isn't great
Related
I've the following problem:
I have an Oracle forms Application where the User can call multiple Forms.
I also have an Menu with an Logout button, that should close all open Forms.
When this button is pressed I set :GLOBAL.LOGOFF to 'TRUE'. And in WHEN_WINDOW_ACTIVATED I have placed the following code.
DEFAULT_VALUE('FALSE','GLOBAL.LOGOFF');
IF (:GLOBAL.LOGOFF = 'TRUE') THEN
COMMIT;
DO_KEY('EXIT_FORM');
END IF;
This whole thing also works when the Oracle Forms Application is called from a browser.
But when I call it via JNLP it crashes the application. I get the following errors:
FRM-40735: WHEN-FORM-NAVIGATE
FRM-40735: WHEN-NEW-ITEM-INSTANCE
FRM-40735: WHEN-WINDOW-DEACTIVATED
All with:
ORA-06508
I don't understand how the Forms Application is reacting differently depending on if it is executed via JNLP or from a Browser.
Although I question why you are doing logoff handling in a WHEN_WINDOW_ACTIVATED trigger, it is possible what you are seeing is related to a known issue. Refer to these Oracle bugs that all map together. You may need to work with Oracle Support as some of the bugs and/or their content may not be visible to you. 9764631, 22724515, 26996652
Also, if you are not already using 12.2.1.3, you will need to update your version in order to get the fix I mentioned.
Helpful resource:
https://community.oracle.com/community/development_tools/forms
I have a strange issue with a Laravel 5.1 application.
Intermittently, it’s dropping session data. I’m detected this by writing some middleware that writes the contents of the session for that request to the log file. Although the session ID (Session::getId()) doesn’t change, the value of _token in the session data retrieved with Session::all() does.
As I say, this happens intermittently. I can refresh the same URL multiple times, and then randomly on one refresh the session data’s gone, and the _token value’s different from the previous requests.
What would cause this? I’ve also noticed the flash object isn’t in the “dropped” session data.
Below is a snippet of the log. You can see the content of the session_data key randomly changes “shape” in the last two lines, but the session ID remains constant.
Also, not sure if it’s pertinent, but I have DebugBar enabled.
UPDATE: Through debugging, I’ve found that on some page loads the session is completely empty, as in, no _token (hence a new one getting generated). Nothing.
If you're using the file driver, you could run into race conditions on concurrent requests. The file then gets truncated, Laravel can't read it, so it refreshes the session. Race conditions can also lead to a symptom where something you're putting to the session just doesn't get put. This tends to be random, so it's very hard to debug. According to the Laravel team, this is a known limitation of the file driver and it does not appear to be getting fixed, so I would suggest using a different driver. This would fix your issue of random session refreshes, but it still introduces a possibility of making a change to the session that doesn't get added. As far as I know, at this point with Laravel 5.1, you'll have to manage that yourself.
Somehow your session data is too long and being truncated. If you're using the database driver (haven't tested other drivers), and you try to save session data that's longer than the field length, then subsequent requests won't be able to pull from this session, and you'll wind up with a new session. If this issue is happening randomly with very short session data, then it's probably the cause listed above.
If you use Linux, Try using Redis (http://redis.io) as session / cache manager in laravel. I had some issues in the past with text / cookies and laravel in some servers. When I instaled Redis I had no problems anymore.
More info: https://laravel.com/docs/5.1/redis
Using a different driver like memcached did not solve the problem for me.
Here is a package that implements session locking which works and very simple to incorporate in your projects.
https://github.com/rairlie/laravel-locking-session
Long story short: I have hacked jasny/sso to work with Laravel. It works extremely well except when the primary/root session has expired.
I have the primary/root authentication set to "remember", so it can reauthenticate from the cookie when the session has expired.
When the 'attach' action happens on the SSO server and the primary/root session has already expired, I am running Auth::check() to bring the session back to life so that it can be attached properly.
All of my debugging indicates that everything is working exactly as I need it to except for this one little detail:
The new session generated by the 'attach' action is never written to the database because the DatabaseSessionHandler thinks it already exists. It is running an UPDATE instead of an INSERT.
As a result, my SSO client session attaches to a non-existent SSO server session.
For the life of me, I can not figure out why it thinks this new session already exists nor how to get it to correctly insert into the database.
Can anyone tell me why a new Laravel 4.2 session would be detected as "exists" and run UPDATE instead of INSERT on save()?
EXTRA DEBUGGING ATTEMPTS --
Attempt #1: I have tracked this to a false attachment to an expired session that hasn't been garbage collected yet. What I don't understand is how this session is being loaded while a different session ID is being presented. If this were the result of the migrate() or regenerate() methods, "exists" would be set to false, and it would save correctly. Somehow, it seems that the session ID is being updated without resetting "exists".
Attempt #2: The answer was staring me in the face the whole time. I kind of understand the downvote now. (see my answer below)
I was dramatically over-thinking this as I tried to uncover the mechanism behind the behavior instead of testing what looked like an easy solution:
If I call Session::setExists(false) prior to Session::save(), it will insert the new session correctly.
EDIT: If wrapped in an if-statement for Auth::viaRemember(), I can check if the auth happened via session or cookie/remember. If true, then I want to set "exists" to false.
We are using Spring session and we observed that the screen was appearing blank sometimes. We noticed that when the screen worked as expected, there was only one session id created. However, when the screen was blank, we noticed two session id being created because of which the data stored in the session was getting lost.
Please let me know if anyone has encountered such issue before and found a solution to it.
Thank You!
I am working on a Play Framework project and I am using SecureSocial plugin for user actions.
My problem is, according to Play Framework document, the session should have been closed and reset when I closed the browser tab and opened a new tab.
But when I close and reopen the tab, I see that the session id is still the same and user logs in directly without reopening the login page (because user info is still available on play session)
Here's the output from before and after I open a session:
Before
session = {sid=86, ___ID=80519f26-ccf9-4e6f-9f9a-0f2a3bbc7b20, securesocial.network=userpass, ___AT=4241355a05e419dabc6e16612275b3d932133707, securesocial.user=test}
And then I close and reopen the browser tab after a few seconds...
After
session = {___ID=80519f26-ccf9-4e6f-9f9a-0f2a3bbc7b20, sid=86, securesocial.network=userpass, ___AT=4241355a05e419dabc6e16612275b3d932133707, securesocial.user=test}
everything is the same. Sometimes it changes randomly.
By the way, I don't have any session settings in application.conf or anywhere else; everything is still in its default setting.
SocialSecure uses cookies - it checks if the user has been authenticated against a certain provider before. Deleting the cookies should allow you to test the functionality from the beginning.
Inside SecureSocial.java (in controllers.securesocial) - you should be able to check where inside checkAccess, getUserId is called (where it checks the cookie values for the user and provider).
Hope it helps
I've realized that this is a new "feature" on modern browsers. Unless you fully close all tabs and the browser itself entirely (in osx, right click and close), the browser wont close the session, so the user doesnt nee dto relog until they completely close the browser..
So in short, your session will not expire with just closing the "tab", but you have to close the "browser" entirely.