A napokban szembesültem a problémával, hogy az egyik alkalmazásomba 10 perc után mindig újra be kellett jelentkeznem. Mindez függetlenül attól, hogy volt-e ebben az időszakban bármilyen aktivitás, vagy csak úgy nyitva maradt az ablak.
Az igazsághoz persze az is hozzá tartozik, hogy ez az egész egy új szerveren történt, tehát kénytelen voltam egy kicsit belemélyedni a konfigurációs lehetőségekbe...
Kezdjük a dolog legalsó szintjéről. Mivel az egész APEX egy oracle db-n fut, és a workspace júzerével csatlakozik, az időtúllépést maga az adatbázis is leszabályozhatja. Mivel közvetlen, (pl. SQLdeveloper) csatlakozás esetén a fenti felhasználóval ez a hiba nem állt fent, gyanítottam, hogy nem az adatbázis dobja el a kapcsolatot. Ha így lett volna, akkor egyébként valószínűleg az SQL profile lett volna a hibás.
Ezt egyébként az alábbi lekérdezéssel könnyen ellenőrizheted, ha van SELECT ANY DICTIONARY jogod:
select * from dba_profiles t where t.profile in (select profile from dba_users where username='<wkspcusr>') and t.resource_name in ('IDLE_TIME','CONNECT_TIME');
Ezen kívül próbálkoztam az sqlnet.ora fájl bővítésével is a következő sorral: SQLNET.EXPIRE_TIME = 5. Ilyenkor a DB 5 percenként küld valami csomagot, hogy legyen valamiféle kommunikáció a klienssel.
Maradt tehát az APEX keretrendszer, annál is inkább erre terelődött a gyanú, mivel fejlesztés során nem magából a workspace editorból lettem kizárva, hanem az alkalmazásból. Az APEX-ban két helyen tudsz ilyen jellegű megszorítást megadni.
Az egyik az adminisztrációs felületen (internal workspace) Home > Manage Instance > Security pontban található, viszont ezeken a kereteken belül magánál az alkalmazásnál is lehet szűkíteni az időtúllépéseket a Shared Components > Security Attributes oldalon. No ez utóbbi bizonyult szűkösnek.
A képen látható, hogy az idő lejáratkor definiálható, hogy melyik oldalon találja magát a felhasználó. Jó nem?
A bejegyzés trackback címe:
Kommentek:
A hozzászólások a vonatkozó jogszabályok értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a Felhasználási feltételekben és az adatvédelmi tájékoztatóban.