We're putting together a web application that allows the user to enter their Pro/Intralink login and password. Then, in the background, we authenticate the user. Has anybody done that? If so, do you have any advise or recommendations on the best way to do it?
This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.
--- - wrote: > > We're putting together a web application that allows the user to enter their > Pro/Intralink login and password. Then, in the background, we authenticate > the user. Has anybody done that? If so, do you have any advise or > recommendations on the best way to do it?
There are a couple of ways that you might do this, but it depends on what functionality the web application is using:
1. Intralink Scripting application (Java) 2. Intralink Toolkit application (C/C++) 3. Oracle SQL application 4. Use LDAP or Active Directory instead
If your application is essentially one or more Intralink Scripting (or Intralink Toolkit) applications, then you can just try to run it with the given login and password. If they are correct, the app runs. In this case you're not really doing any authentication, but rather passing the responsibility to Intralink.
If you're running SQl queries, then you wouldn't want to startup the client with every request. An Intralink based application method would be pretty slow if used like that, but it could work.
Another way, would be to create a web services front end controlling a persistently running Intralink session that validates passwords. It would do nothing more than to login/logout and indicate if a password was valid. If the client was already running, then this would be pretty fast, but problematic if multiple users are hitting the site at the same time.
Looking in the Oracle tables directly would be great, but the passwords are "encrypted" either as MD5 checksums or using Oracle's Ofuscation Toolkit (or something similar). Unless you can figure out which method was used, this isn't going to work.
If the OS user IDs are the same as the Intralink user IDs, then #4 could be the less problematic solution. More companies have done this to authenticate users on a internal websites, than try to authenticate against Intralink passwords. As a result you will find more help on this method than any other. If you're trying to do something with an Intralink client session, this won't work at all.