Authentication scheme affecting report formatting

Question

Hi all,
I'm new to HTMLDB, and using 1.5.0.00.33. Super product. All was going splendidly until...
I created an authentication scheme ('ANIX') from scratch. Its function checks agains database users, and performs correctly. It uses login page 101. All other parameters defining the scheme I left at defaults.
I have some multi-column sql reports which include a text column (call it FRED) with typical contents of say 500 to 2000 characters.
With HTML_DB as the current authentication scheme, column FRED wraps as expected, and reports render correctly.
With ANIX as the current authentication scheme, column FRED doesn't wrap, so report tables no longer size to the width of the browser window - they extend way to the right in an unacceptable manner.
I can toggle between correct and incorrect report displays by switching which auth scheme is current. This happens whatever report template I use.
Anyone shed light on this please?
Thanks,
John D

Answer 1

Hi Scott,
Thanks for prompt reply.
Auto-sizing of columns and wrapping of cell contents to fit (e.g. in columns of a <table width="100%">) is default HTML behaviour, no? - as with the paragraph you're reading right now.
Clearly authentication shouldn't have any thing to do with it. But that's what's happening...
I'd like to install on oracle.com, but the dependencies of the app on objects and data in other schemas (users, tables etc. in the 'main' transactional database) make this a prohibitively complex task at this stage.
Perhaps I could sort out some access for you to the app in situ? (First I'll have to find out how - it's all behing firewalls etc at the moment).
If it helps, the authenticate function is below.
John
create or replace function authenticate_u_p
( p_username in varchar2,
p_password in varchar2
return boolean
-- Called from the htmldb login procedure
as
l_account_status varchar2(32);
l_old_expiry_date date;
l_old_encrypted varchar2(30);
l_new_encrypted varchar2(30);
l_stmt varchar2(255);
begin
if p_username is null
or p_password is null then
return false;
end if;
begin
select account_status
into l_account_status
from sys.dba_users
where username = upper(p_username)
and account_status <> 'LOCKED';
exception
when no_data_found then
-- The user doesn't exist or account is locked...
return false;
end;
-- Get the user's current password...
begin
select password,
expiry_date
into l_old_encrypted,
l_old_expiry_date
from sys.dba_users
where username = upper(p_username);
exception
when no_data_found then
-- The user doesn't exist...
return false;
end;
-- We have the encrypted value of the current password, but only the plain value of the supplied password.
-- To compare the current and supplied passwords, we have to:
-- - 1. change the user's password to the supplied parameter (which encrypts the value)
-- - 2. obtain the encrypted value of this new password
-- - 3. compare the two encrypted values
-- 1. change the user's password to the supplied parameter (which encrypts the value)...
l_stmt := 'alter user '||p_username||' identified by '||p_password;
execute immediate l_stmt;
-- 2. obtain the encrypted value of this new password...
begin
select password
into l_new_encrypted
from sys.dba_users
where username = upper(p_username);
exception
when no_data_found then
-- This should never occur, but let's be safe...
return false;
end;
-- 3. compare the two encrypted values...
if l_old_encrypted <> l_new_encrypted then
-- Change the password back to its old value...
l_stmt := 'alter user '||p_username||' identified by values '||chr(39)||l_old_encrypted||chr(39);
execute immediate l_stmt;
end if;
if l_old_expiry_date < sysdate then
l_stmt := 'alter user '||p_username||' password expire';
execute immediate l_stmt;
end if;
return l_old_encrypted = l_new_encrypted;
end authenticate_u_p;