function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
eclfeclf 

Login/Session Validation -- visualforce component

Hello SF people out there!

 

So I've got a situation:

I'm building a site where users can register and login and do stuff. I would like to create a system that when the user logs in, it sets a cookie and when he jumps from page to page, it does a verification of the user's session. I thought about doing this using a visualforce component and putting it in every page; basically, the users logs in, creates the session and every page he goes the component has an action to perform the verification. And I would onky have to code this once, rather than doing this for every controller of every page.

 

1st -- I would like to know if this is a good approach? Or if there are other/better ways to do this? 

 

2nd -- Can I call this verification function (from the component controller) on page load and then send it to login page if it's doesn't verify? I tryed using actionFuntion but it seems it's not calling the function, I have nothing in log.

 

Anyone who has some insight in this... please.

 

Thank you.

 

sfdcfoxsfdcfox

If I recall correctly, you can't legally build your own authentication system, it's not allowed by the terms and conditions of using Sites. Instead, you can purchase High Volume Portal Licenses (or whatever they're called these days) Authenciated Website User licenses. This gives you the ability to have your visitors register against your accounts/contacts in salesforce, manage their passwords, enable sharing and security, and even disable them individually. It also gives you the same standard session management that you'd expect with regular users; session timeout is automatically handled for you, expired logins are automatically redirected to your Site's login page, and they can reset their own passwords through the Site. In short, the answer to the first question is, no, it's not a good approach, because there's a standard mechanism to do this, and the answer to the second question is that you don't need to write any components at all if you leverage the standard system functions. The last I heard, this feature ran at about $1500/year for many licenses (80,000?), but you should contact sales to be sure. As a developer, you can also probably request a few demo licenses for testing purposes only.

eclfeclf

Hello,

 

Well if you have a service, implemented in salesforce and this service has users (not SF users!),  you can't have a login page for these? Imagine you have a site built in SF and you manage users for that site.

 

Thanks for the reply.

 

eclf

sfdcfoxsfdcfox
It's not that it's technologically impossible, it's simply not advised. Even though they're not users in the "normal" sense, their identity is managed by the platform, including their user name, password, and security. This makes it far easier to, for example, make a website that has users that are not full CRM users. For example, mystarbuckideas.com (for Starbucks, obviously) is built on the force.com platform, uses Sites, and allows them to submit, view, and promote ideas that they'd like to see Starbucks do, like being more environmentally friendly or offering perks such as free coffee programs. The entire site runs on the force.com platform; the users are managed internally as salesforce.com users, but they can't access Starbuck's organization data, except for what they're allowed to see. They also can't go to login.salesforce.com, as their username and password is no good there; only logging into mystarbucksidea.com will grant them access. In fact, if a visitor is not paying attention, they wouldn't even notice that the entire site is indeed a salesforce.com-driven application. It's not that you can't have a login page (because you obviously must be able to), but rather it's a question of who is maintaining the security and identity of these users (a custom-built, possibly bugged implementation that could leak data or allow users to be compromised versus a standardized, secured, and managed implementation). As a bonus, since they log in to standard mechanisms, your code gains the ability to use UserInfo to get a customer's information, the setPassword and resetPassword APIs, and all the other benefits of managing regular salesforce.com users. I personally contemplated creating a portal on salesforce.com at one point, but I realized that, even though my own grasp of security is strong, it would be tough to properly implement without running into the sort of questions you're asking.
eclfeclf

Hello

 

eclf