Develop Reference

Can't connect to Firebird 3.0 with user with small letters in login with Java

I connect with names in capital letters, but it does not want to connect with small letters in the login.
Here is a small test
String ENCODING = "WIN1251";
String CONNECTION_URL = "jdbc:firebirdsql:localhost:C:/ProgramData/test.FDB";
Properties properties = new Properties();
properties.setProperty("encoding", ENCODING);
properties.setProperty("roleName", "GUEST");
properties.setProperty("user", "smoll2");
properties.setProperty("password", "1234567a");
DriverManager.getConnection(CONNECTION_URL, properties);
java.sql.SQLInvalidAuthorizationSpecException: Your user name and password are not defined. Ask your database administrator to set up a Firebird login. [SQLState:28000, ISC error code:335544472]
at org.firebirdsql.gds.ng.FbExceptionBuilder$Type$4.createSQLException(FbExceptionBuilder.java:572)
at org.firebirdsql.gds.ng.FbExceptionBuilder.toFlatSQLException(FbExceptionBuilder.java:302)
at org.firebirdsql.gds.ng.wire.AbstractWireOperations.readStatusVector(AbstractWireOperations.java:138)
at org.firebirdsql.gds.ng.wire.AbstractWireOperations.processOperation(AbstractWireOperations.java:202)
at org.firebirdsql.gds.ng.wire.AbstractWireOperations.readOperationResponse(AbstractWireOperations.java:161)
at org.firebirdsql.gds.ng.wire.version13.V13WireOperations.authReceiveResponse(V13WireOperations.java:122)
at org.firebirdsql.gds.ng.wire.version10.V10Database.authReceiveResponse(V10Database.java:569)
at org.firebirdsql.gds.ng.wire.WireConnection.identify(WireConnection.java:309)
at org.firebirdsql.gds.ng.wire.FbWireDatabaseFactory.performConnect(FbWireDatabaseFactory.java:51)
at org.firebirdsql.gds.ng.wire.FbWireDatabaseFactory.connect(FbWireDatabaseFactory.java:39)
at org.firebirdsql.gds.ng.wire.FbWireDatabaseFactory.connect(FbWireDatabaseFactory.java:32)
at org.firebirdsql.jca.FBManagedConnection.<init>(FBManagedConnection.java:141)
at org.firebirdsql.jca.FBManagedConnectionFactory.createManagedConnection(FBManagedConnectionFactory.java:550)
at org.firebirdsql.jca.FBStandAloneConnectionManager.allocateConnection(FBStandAloneConnectionManager.java:65)
at org.firebirdsql.jdbc.FBDataSource.getConnection(FBDataSource.java:124)
at org.firebirdsql.jdbc.FBDriver.connect(FBDriver.java:137)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:208)

There are basically four situations where this authentication error will happen:
The user does not exist or has the wrong password
You created the user with a case-sensitive username, e.g. using CREATE USER "smoll2" ....
You created the user with the Legacy_UserManager, and are using Jaybird 4, which by default no longer authenticates with Legacy_Auth
The user is marked inactive
I assume case 1 doesn't apply here, but otherwise you need to create the user or change its password.
For case 2, it is important to realise that - since Firebird 3.0 - usernames are identifiers, and follow the same rules as identifiers. Which means unquoted names are stored in uppercase, and match case-insensitively (by means of uppercasing), while quoted names are stored exactly and are compared as is. If you created the user case-sensitively (CREATE USER "smoll2" ...), then you need to authenticate with a quoted user name:
properties.setProperty("user", "\"smoll2\"");
If you don't do this, you are actually authenticating against the user SMOLL2 (which doesn't exist).
For case 3, since Firebird 3.0, Firebird provides multiple authentication plugins with accompanying user managers. Users exist per user manager. Since Jaybird 4, Jaybird by default only authenticates with plugins Srp256 and Srp (which share the Srp user manager). If you created your user with the Legacy_UserManager (either because it is the first configured in UserManager in firebird.conf, or because you used the using plugin Legacy_UserManager clause when creating the user), you cannot authenticate with the default settings of Jaybird, because it doesn't try the Legacy_Auth user plugin.
There are two solutions for this case:
Drop the user with the Legacy_UserManager and create it with the Srp user manager
Configure Jaybird to also try Legacy_Auth:
properties.setProperty("authPlugins", "Srp256,Srp,Legacy_Auth");
If you only want to try Legacy_Auth, you can remove Srp256 and Srp from the list.
As a variation of case 3, this can also occur if you have a custom user manager and authentication plugin which is not supported by Jaybird.
Finally case 4, a user can be inactive (either because it was created with the INACTIVE clause, or altered to inactive). An inactive user is not allowed to authenticate. The inactive state is ignored for Legacy_UserManager/Legacy_Auth. If a user is inactive, you can activate it again with:
alter user smoll2 set active
Be aware that it could also be a combination of 2 and 3 (using a case-sensitive username and Legacy_UserManager). You can verify which user you have, if it is active, and for which user manager, by executing the following query as SYSDBA or a user with RDB$ADMIN role in the current database and the security database:
select sec$user_name, sec$active, sec$plugin from sec$users;
For Legacy_UserManager, the SEC$ACTIVE column is NULL, as it doesn't support the active/inactive state.

Sessions handling in Vaadin

I have a Vaadin application that starts with a user login, but the problem is with Vaadin is the session handling as I can open two sessions from 2 different browsers with the same login which should not be possible to do. But I did not find any documentation regarding that besides this topic but it's not working properly as the data are not saved in the hashmap correctly.Anyone got the same problem?

Vaadin 7 works by default so that it creates everytime a new UI instance when a new browser tab is opened (or the tab is refreshed). You should store information about current user to VaadinSession or standard HttpSession and check in UI.init() if the session contains user information.
To store information into VaadinSession one can say:
VaadinSession.getCurrent().setAttribute("currentUser", currentUser)
HttpSession can be accessed as follows in Vaadin:
VaadinSession.getCurrent().getSession()
Please note that VaadinSessions are stored into HttpSession and HttpSession can contain multiple VaadinSessions if multiple Vaadin servlets are deployed from the same war file, and the user uses those at the same time.

How to prevent concurrent logins?
I keep track of logins using a self-generated login-token. A random string between 32 and 128 bytes in length that gets stored in a cookie and a backend database, typically under a user's account.
If User (A) shares her login credentials with User (B) a new login-token is generated for the new login and stored in a cookie and updated in the backed database.
If User (A) (who might for example already be logged in) attempts to perform an action while User (B) has just logged-in, User (A)'s session will be destroyed and she'll be redirected to the login screen after a backend test confirmed her login-token isn't a match.
Think of Sessions and Logins as two different things. Sessions can be generated all day long, but login STATE should be stored in a central store.

You can save all logged users to static Set. Static variables are globally shared. On start app, check whether the collection is already login.

Connecting Java and Teradata: The UserId, Password or Account is invalid

I have been trying to connect to Teradata
Class.forName("com.teradata.jdbc.TeraDriver");
String connectionString = "jdbc:teradata://xxx.xxxxxx.com/database=xxxxxx, tmode=ANSI, charset=UTF8";
String user = "Rocket512";
String password = "aui8mn5";
Connection conn = DriverManager.getConnection(connectionString, user, password);
Got the following
Exception in thread "main" com.teradata.jdbc.jdbc_4.util.JDBCException: [Teradata Database]
[TeraJDBC 14.10.00.17] [Error 8017] [SQLState 28000] The UserId, Password or Account is invalid.
at com.teradata.jdbc.jdbc_4.util.ErrorFactory.makeDatabaseSQLException(ErrorFactory.java:300)
at com.teradata.jdbc.jdbc.GenericLogonController.run(GenericLogonController.java:666)
at com.teradata.jdbc.jdbc_4.TDSession.<init>(TDSession.java:216)
I know that the host is specified correctly since i did not get UnknownHost Exception.
Also I have double checked my userid and password are correct.
I ran query suggested by #beni23 (thank you)
select *
from dbc.logonoff
where logdate >= date '2013-10-31'
Here is the result that I got
What is Bad Password? I used SQL Assistant with this very password and it works great. Why cannot i connect with Java?

LDAP Authentication failures will not be captured in DBC.LogOnOff as a Bad Password event because the authentication doesn't take place on the database.
Typically the error message you are receiving, The UserId, Password or Account is invalid., is indicative of the user account being locked on the database.
SELECT U.UserName
, U.ProfileName
, U.DefaultAccount
, COALESCE(P.MAXLOGONATTEMPTS, S.MAXLOGONATTEMPTS) AS MaxLogonAttempts_
, U.LockedCount
, U.LockedDate
FROM dbc.UsersV U
LEFT JOIN
dbc.ProfileInfoV P
ON P.ProfileName = U.ProfileName
CROSS JOIN
dbc.SecurityDefaults S
WHERE UserName = 'Rocket512';
If LockedCount is not 0 than a failed logon attempt has occurred since the last successful logon to the database.
If LockedDate is not NULL it represents the date which the account was last locked.
MaxLogonAttempts_ will tell you how many times you can attempt to logon using database authentication (TD2) before the account is locked.
A couple of things I would suggest:
Remove whitespace between the parameters of connectString
Put the User and Password parameters in the connectString
Using original code above modify the connectString to add: ,ACCOUNT=$AMRWRW&DrT&r which should match what is returned by the query in my response above (I have added DefaultAccount).
EDIT: 11/12/13
May I suggest you download Teradata Studio Express and attempt to make a connection to the same Teradata system using JDBC much like you are here in your code. This may help shed light on the parameters you need to specify in your connection string in order to make the connection successful. You should be able to setup your connection parameters in Teradata Studio Express the same as you have here in your code and see if it works.
Using LDAP as the logon mechanism for a user that has not been granted the explicit right to logon with a NULL password has resulted in the error message `The UserId, Password or Account is invalid.'. I received this the other day using a privileged account without changing my logon mechanism from LDAP to TD2.
What does the following SQL return?
SELECT *
FROM DBC.LogonRulesV
WHERE UserName = 'Rocket512';
It may not return anything, which is okay. This simply means you ability to logon with that userid from any host on the system has not been explicitly granted or revoked.
EDIT: 05/22/18
The “Bad Password” event for an externally authenticated user may will appear in the event log when the provided password and the what is stored on the directory server do not match. In certain scenarios you can verify this by using ldapsearch from the PDN to submit an inquiry directly to the LDAP directory. You can find more details about using this command in the Security Administration manual. I’ve discovered this trying to triage a problem with a subset of user accounts that fail to authenticate to the directory. I felt it would be appropriate to update this answer with more details as my lead in statement at the top is not 100% accurate.

The following might not give you a solution, but might point you in the right direction. I think you'll want to check the dbc.logonoff table in teradata through a console to make sure that your user is not locked or get an idea whether your driver is hitting teradata.
select *
from dbc.logonoff
where logdate >= date '2013-10-31'

Reading this article Troubleshooting Security: The UserId, Password or Account is invalid. we can see the typical reason of this error.
Cause: LOGMECH=LDAP is specified, and the username/password credentials
are redundantly provided in the both LOGDATA and as separate
connection parameters.
Solution: Identify LDAP users via LOGDATA, or
via separate username/password parameters, but not both
simultaneously.
So, you should check this case. May be you can get connection without user/password

Perhaps you might have more luck with:
String driver = "com.teradata.jdbc.TeraDriver";
String conUrl="jdbc:teradata://xxx.xxxxxx.com/database=xxxxxx,USER=Rocket512,PASSWORD=aui8mn5,tmode=ANSI,charset=UTF8";
Class.forName(driver);
Connection dbConn = DriverManager.getConnection(conUrl);
If that doesn't work make sure to use the latest jdbc driver.

I had similar error and followed all the suggestions given in here. My account was not locked and I was able to connect to the DB with the same username and password, via SQL assistance editor.
The solution worked for me was adding following line in the connection string: LOGMECH=LDAP.
You need to know the logon mechanism for your Teradata, or you can reach out to your DBA team, as I did. So your connection string will look something like this:
String connurl="jdbc:teradata://xx/database=xx,USER=xx,PASSWORD=xx,tmode=ANSI,charset=UTF8,LOGMECH=LDAP";

What is a good strategy to manage sessions for beta webapplication?

I am trying to create a webapplication using Spring. The webapplication is a beta/demo site, which is invitation only. So, I need to generate a link to the webapplication url, appending a unique id, which would be valid for 24 hours. User can use that link for 24 hours and make use of the (I kind of also have plans of restricting the user by ip)
To achieve such token generation and expiry, should I just rely on the container with session time out to do it? or does it make sense to create spring backed service layer with token creation and expiry services?
EDIT
Now that I have a bounty on this to draw more attention, I thought I will rephrase the question so that it makes more sense - what would be a good strategy to force users out of a web application after a certain period of time?

Relying on session timeout would not be sufficient solution .
I am not acquaint with Spring . I would put my generic solution as below for any web application having requirement as yours :
Invitation is assumed to include a link to the Web Application .
The link is assumed to include the unique id .
The Beta/Demo user table is assumed to have a beta-expiry ( datetime ) column to hold the expiry date and time .
When your web application is accessed using the link in the invitation , update the beta-expiry column for that unique_id considering 24 hrs from then .
When a Beta/Demo user attempts to sign in , check the beta-expiry column for that particular user and allow access if the expiry is not reached . Display appropriate message in case of expiry .
Whenever a signed in Beta/Demo user performs subsequent accesses to your web application , check the beta-expiry column for that particular user and allow access if the expiry is not reached . Display appropriate message in case of expiry .
If seems useful , display a countdown timer showing the left over time somewhere in the header area .
In case of extension of Beta usage for all or a portion of users , you could update the beta_expiry column appropriately .
Additionally you could also have an invitation-expiry column to hold invitation expiry considering a particular duration for eg. a 48 hrs from when the invitation was sent .
We use a little bit similar solution to sign out ( signed in ) users from our SaaS application after a particular duration of no access .

I think that you should rely more in the back-end rather than a session on a cookie, imagine the case that you set the cookie for 24 hours expiration but the client deletes the cookies from the browser, (depending on your logic) your link will generate a new session or the request will be blocked.
IMHO you can store a session cookie on the client but you need to have a second source of comparison in the server, maybe a database, no-sql document, a collection in cache, something that you can compare and check the latest access to the client.
just to put all together imagine the following use case:
the user get the invitation link and click on it
the system check if the first time they log into the system, and save that date as a "start date" and another one as "last access"
the system sets an authentication cookie with 24 hours expiration
the system track every post back/ ajax call to the server and update "last access" date
if user deletes the cookie the system check the "last access" and make a comparison with the current server date
if valid the system creates a new auth cookie with the remaining hours
if not valid the system sends a message to the user.
for the user the cookie will expire according to the time left (calculation between start date and last access)
I hope this helps.
regards

One strategy is to keep track of expiry date-time of all the users by storing the relevant data in DB and using a cache library (to reduce DB hits while checking for the expiry date). Here is a small example:
Create a DB table with columns to map user id to expiry date: id, unique_user_id, expiry_date_time. You need to create the unique user id in your code and save it in DB before sending the URL to the user with this id. You can keep null as the initial value for expiry_date_time. Create a class to represent this mapping in Java:
class UserIdWithExpiryDate{
private String userId;
private Date expiryDateTime;
...
}
Define a Service with a cacheable method that will return an instance of this for a given userId :
public interface CacheableService {
#Cacheable("expiryDates")
public UserIdWithExpiryDate getUserIdWithExpiryDate(String id);
public void updateUserIdWithExpiryDate(String userId);
}
import org.joda.time.DateTime;
#Service
public class CacheableServiceImpl implements CacheableService {
#Autowired
private YourDao dao;
#Override
public UserIdWithExpiryDate getUserIdWithExpiryDate(String id) {
return dao.getUserIdWithExpiryDate(id);
}
public void updateUserIdWithExpiryDate(String userId){
Date expiryDate = new Date(new DateTime().plusHours(24).getMillis());
dao.update(userId, expiryDate);
}
}
The result of getUserIdWithExpiryDate method is stored into the cache so on subsequent invocations (with the same argument), the value in the cache is returned without having to actually execute the method.
Next step is to check the user's expiry date while accessing the site. This can be done using OncePerRequestFilter:
#Component("timeoutFilter")
public class TimeoutFilter extends OncePerRequestFilter {
#Autowired
CacheableService cacheableService;
// Here you need to decide whether to proceed with the request or not
#Override
protected void doFilterInternal(HttpServletRequest request,
HttpServletResponse response, FilterChain filterChain)
throws ServletException, IOException {
filterChain.doFilter(request, response);
}
}
Steps that can be taken inside the doFilterInternal method to check the validity of the user:
Get the user Id from request
Execute: cacheableService.getUserIdWithExpiryDate(userId)
If step 2 returns null, there is no user present with this id. You should not proceed with the request.
If step 2 returns an instance of UserIdWithExpiryDate, check the value of "expiryDateTime"
If the value of "expiryDateTime" is null,it means user is accessing the site for the first time.Update "userExpiryDate":cacheableService.updateUserIdWithExpiryDate(userId) and proceed with the request.
If "expiryDateTime" is not null, compare this with current date_time. If expiryDateTime.isAfter(currentDateTime), proceed with the request.
For caching, you can use Spring Cache Abstraction with EHCACHE.

Tokens
For this marketing purposes we generate tokens upfront, store them in a database alongside all information like restrictions to certain user account, ip ranges (for certain mobile carriers), the date and time ranges of use and so on.
In case of one time codes we just mark it as being used in the database.
To generate those codes we use Random Numbers or encode some information and use (SHA-1 or better). Then we use bigInteger.toString(36) or a different scheme and group the first 16 letters to let it look like a license key.
If we express information with it like useraccount/name or carrier (mobile) or whatever we can even validate the token without a database.
Forcing User Out
Just check for the validity of the token the first time the user starts a session or logs in. Throughout the session you just check if the token has expired (store a value in the session if you have one, append it (encrypted) in the url or whatever or check against a database.
So on every request you just check if the user has permission to access your site otherwise you block the user with an error / info page.
You can also add a java script to each page. The script can determine whether the users permission to use your site has expired by:
Encrypt the relative time that the token is valid in a hidden div and calculate the absolute time using the users local time. Then compare the absolute expire time with the user time every now and than (lets say every 3 seconds) and you can yourself all those polling and pushing (comet, ajax, websockets) behaviour.
Once the java script program notice the token has become expired remove the content sections and replace it (or mark a hidden div as visible) with the info / error page content. This way every time the user revisits pages still stored in the browser history are destroyed also. (if this is a necessity for you).
Summary
Use random tokens and a database or encrypt information (like the day the token can be used) and SHA-1.
Check the tokens validity every time the user requests a page (store the timeframe in a session / url to save roundtrips to the database)
Provide a java script that destroys local pages in the history on revisit.

Here I can think of two use cases that I have seen.
1.) This kind of management is used in applications like online tests or email verifications, where user is provided a link with some token. This link and the token is valid for some fixed period of time and can be used only once. (Ex. online tests or password reset-emails)
2.) Another use case is to provide link with a token which are also valid for a fixed period of time, but in this case the link and the token can be used any number of time within the time period allowed (Ex. Online registration forms for test or some university enrollments).
So, definitely managing this using a session only will not be a good choice as the browsers can be cleared.
So you need to maintain the pair of the link and the token at the server (May be in a DB) with some other information like last accessed time, creation date and time, Valid upto .
To be more flexible validity time for link and the token can be set differently (eg. link can be used for a set of users, but the tokens are unique to a user).
So you can use this info on every user visit to check whether the link or token is still valid and what are their last accessed time. If it turn out to be expired then you can show the relevant error message.

What about "deleting the user's account" (depends on how you are building your logging system) after 24 hours.
Coupling this with checking user's account every time (s)he loads the page, will force him/her out at the first refreshing after the 24 hours threshold passses.

You can store the id with expiration time and when a request comes in with that id check if
it's still valid
and if you are trying to accomplish something like id is valid say 5 hrs after first request then store time when the first request is made and for each subsequent request check if it's still valid

lock logged in user in oracle by java

i have one java web application in jsp and servlet and db as oracle 10g EE. In login if one user has been logged in then how can i prevent same user from logging again unless sign out?
Note: I am not telling that if a logged in user will click on login page then immediately he would be forwarded to his home page.
I am asking is how can i prevent that logged in user to login again if he is already logged in. Suppose user A is already logged in into the db(sign out not done), then user B tries to login in to db with the user id and password of user A, then simply user B will be prevented from login. How do i implement that?

You need to manage a map of logged in users, Map<String, String> userToSessionIdMap when user logs in you check if there is any session exist for this user name if yes deny else allow login,
Now on logout you need to remove the entry from map, also you need to implement HttpSessionBindingListener so when session expires it removes the entry again
Also See
prevent multiple login using the same user name and password
Preventing multiple login

Let the database do it's own job!
(This solution assumes that you can get help from DBAs; or you have SYSDBA access to the database.)
First create a profile that allows only 1 session per user:
CREATE PROFILE single_session_profile
LIMIT SESSIONS_PER_USER 1;
Then create the user with the right profile or alter an existing user to use the profile:
CREATE USER user_a
IDENTIFIED BY user_id
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users
PROFILE single_session_profile;
or
ALTER USER user_a
PROFILE single_session_profile;
Finally, the database needs to be observe these limits:
ALTER SYSTEM SET RESOURCE_LIMIT = TRUE SCOPE = MEMORY;
(SCOPE = MEMORY enables limit enforcement for the currently running database instance; if you want to make it persistent, i.e. enabled after a database restart, you need to use SCOPE = BOTH where BOTH means both MEMORY and SPFILE, i.e. DB initialization file. If the database does not use the new SPFILE format, but the old PFILE (init.ora), then you need to add the RESOURCE_LIMIT setting to the init.ora and restart the database.)
That's it. If a user_a tries to log in twice, it will get:
ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit