Tim,
We have a CRM (Customer Relationship Management) system that we are using
in conjunction with IMail. We authenticate through username/password in
a SQL table that is also used by IMail (external DB). Users can track
sales leads, customer contacts, check inventory, and use our proprietary
calendaring in one application and check email through a link to the IMail
server. We are writing our own web interface on the CRM server in ASP/COM
to add our own customized functions and make the interface generally more
secure.
> 1)the webmail interface IS the website itself. So, it would involve
> fletching the entire site in the webmail interface.
> 2)the site checks whether you're logged into webmail and gives you access
> accordingly. This could work with the webmail cookie, although it would
mean
> the webmail session may not expire, or at least the access to webmail may
> not expire, until user logs out by himself.
- Application within the IMail web messaging server: As far as general
math, logic, and database operations are concerned, you're pretty limited
in the programming tools available within IMail's web messaging server.
Basically, you can customize the look & feel of the web messaging templates.
If you wanted to look up data, do math, or reporting, there isn't much
the IMail web server can do for you. It wasn't built for that sort of
thing.
- If you run your application on one domain and the mail server on another,
your application WILL NOT be able to read cookies from the mail server (and
visa versa)... security thing. I'm not sure if this works across the same
domain, but different ports. You'll still have to figure out how to get
IIS to run with IMail on different ports. I forgot who it was, but someone
on this list figured out how to do it.
- Cross domain frames will work as long as you don't need to get data back
and forth. Another security thing.
> "if you have a more that mail to do with the web interface, then you have
to
> write that app, and then in that app, have a link to the webmail
> function. There are ways to pass the authenticated user from one app to
> the webmail app.
Unfortunately, most methods of doing this aren't very secure. These are all
Windows type of methods. I assume that's going to be your platform since
you
mentioned .NET. You can:
1) Look up username and password and insert them into a
"hidden/automatically
submitting" form. This isn't exact ASP code, but you get the idea:
<form method="post" action="http://www.imailserver.com:8383/login.cgi";
id="myForm">
<input type="hidden" name="username" value="<%=strUsername%>">
<input type="hidden" name="password" value="<%=strPassword%>">
</form>
<script language="javascript">
document.all["myForm"].submit();
</script>
One problem is that the page may be cached and you've got the username and
password stuck somewhere on the computer. I assume that an e-learning kind
of site will be on computers used by multiple people.
Remember also that you're not really "passing the authenticated user from
one
app to the webmail app". You're just logging into the IMail server without
the
client really seeing the login screen.
2) You can use ASPHTTP or XMLDOM objects to post directly to the IMail web
server
and read the HTTP or XML responses to post on your web server. Now, I'm
no master programmer, but this was a real pain and it's extremely
inefficient.
Just try displaying the main menu from IMail on your IIS server and you'll
see
what I mean. You've got to essentially open and close an HTTP connection to
the IMail server on EVERY ASP page hit.
3) I haven't tried this, but it was suggested to me. It may be possible to
run
the IIS web site and IMail web site on the same domain, but different ports.
Then,
you can store the username and password in a cookie that can be read by both
sites.
You can login through your IIS site, store the username/password in a
cookie. When
your client clicks on the web mail link, the login page can check for the
existence
of this cookie and automatically log you in. Again, it's just a separate
login...
not the same security context really. That means you can pretty much forget
maintaining state. The security problem here is having to store the
username and
password combo on the client machine (even if it's for a limited time).
> function. There are ways to pass the authenticated user from one app to
> the webmail app.
If there really is a way to do this, I'd like to know! This problem plagued
me
for weeks!
-Norm
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Please visit the Knowledge Base for answers to frequently asked
questions: http://www.ipswitch.com/support/IMail/
