• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Need some coding help... https forms.

Scarpozzi

Lifer
We've got a login page that we've developed. The username and password were sent via a html form, initially cleartext. We used a packet sniffer to find this out for a fact and rebuilt the page. It now uses the post command and sends to a secure site, the only problem is that once it sends, we're stuck with the https:// and all of the other pages linked within the main page a user goes to (after logging in) gets those messages asking them if they want to view insecure data. Any suggestions?

Thanks.
 
Make all your URLs relative, so they all stay within the HTTPS protocol.

That includes all image tags and such too
 
Originally posted by: Superwormy
Make all your URLs relative, so they all stay within the HTTPS protocol.

That includes all image tags and such too
We thought of that. However, the problem is that we have some weird configurations on the servers that we are using and the security certificates don't always match the servers because many are clustered. We're working on getting a cert. from verisign, but that will take a little while. I'm looking for a solution that might somehow only use https for the post on the authentication and then go back to http. For the number of people authenticating from this site, I'd like to keep encryption to a minimum to keep the server from doing extra work as well.
 
It sounds like you're posting to the same page that that user would see if they successfully authenticated. What I would do is this:

html forms-based login -> interim authentication page -> final page

i.e. have the authentication page do just that: authenticate. If it fails, redirect them back to the login page. If it succeeds, redirect them to whenever authenticated users go. The redirection gives you full control.
 
Thanks. I think we found the solution. Another team is using the same portal we are and they ran into the same issue. They ended up doing a type of java redirect and threw that up in the header of the next page. I should be able to do a viewsource and get enough information to reverse-engineer their portal login. 🙂
 
Back
Top