Length of time after
which the system logs out inactive users. Select a value between 15 minutes
and 12 hours. Choose a shorter timeout period if your organization has
sensitive information and you want to enforce stricter security.Note

The last active
session time value isn’t updated until halfway through the timeout period.
That is, if you have a 30 minute timeout, the system won’t check for activity
until 15 minutes have passed. For example, assume you have a 30 minute timeout
value. If you update a record after 10 minutes, the last active session time
value won’t be updated because there was no activity after 15 minutes. You’ll
be logged out in 20 more minutes (30 minutes total) because the last active
session time wasn’t updated. Suppose you update a record after 20 minutes.
That’s five minutes after the last active session time is checked, so your
timeout resets and you have another 30 minutes before being logged out, for a
total of 50 minutes.

Disable session
timeout warning popup

Determines whether
the system prompts inactive users with a timeout warning message. Users are
prompted 30 seconds before timeout as specified by the Timeout value.

Lock sessions to the IP address from which they originated

Determines whether
user sessions are locked to the IP address from which the user logged in;
helping to prevent unauthorized persons from hijacking a valid session.Note

This may inhibit
various applications and mobile devices.

Require secure connections (HTTPS)

Determines whether
HTTPS is required to log in to or access Salesforce, apart from Force.com
sites, which can still be accessed using HTTP.

This option is
enabled by default for security reasons. It should not be disabled. Once this
preference is set to require HTTPS, you can’t manually change it. To change
to HTTP, contact your salesforce.com representative.

The Resetting
Passwords page can only be accessed using HTTPS.

Force relogin after
Login-As-User

Determines whether
an administrator that is logged in as another user is returned to their
previous session after logging out as the secondary user.

If the option is enabled, an administrator
must log in again to continue using Salesforce after logging out as the user;
otherwise, the administrator is returned to their original session after
logging out as the user.

Require HttpOnly
attribute

Restricts session ID
cookie access. A cookie with the HttpOnly attribute is not accessible via
non-HTTP methods, such as calls from JavaScript.Note

If you have a custom or packaged application that uses
JavaScript to access session ID cookies, selecting Require HttpOnly attribute
breaks your application because it denies the application access to the
cookie. The Developer Console and AJAX Toolkit debugging window are also not
available if the Require HttpOnly attribute is selected.

Enable caching and
password autocomplete on login page

Allows the user’s
browser to store usernames. If enabled, after an initial log in, usernames
are auto-filled into the User Name field on the login page. This preference
is selected by default and caching and autocomplete are enabled.

Enable SMS-based
identity confirmation

Enables users to
receive a one-time PIN delivered via SMS. Once enabled, administrators or
users must verify their mobile phone number before taking advantage of this
feature.

Login IP Ranges

Specifies a range of
IP addresses users must log in from (inclusive), or the login will fail.
Users need to activate their computers to successfully log in from IP
addresses outside this range.

To specify a range,
click New and enter a lower and upper IP address to define the range.

This field is not
available in Enterprise, Unlimited, and Developer Editions. In those
editions, you can specify valid IP addresses per profile.

Enable clickjack
protection for non-setup Salesforce pages

Protects against
clickjack attacks on non-setup Salesforce pages. Clickjacking is also known
as a user interface redress attack. Setup pages already include protection
against clickjack attacks. (Setup pages are those pages accessed from the
left side of the screen after clicking Your Name | Setup
on the upper-right part of the user interface.)

Enable clickjack
protection for non-setup customer Visualforce pages

Protects against
clickjack attacks on your Visualforce pages. Clickjacking is also known as a
user interface redress attack. Warning

If you use custom Visualforce
pages within a frame or iframe, you may see a blank page or the page may
display without the frame. For example, Visualforce pages in a page layout do
not function when clickjack protection is on.

3. Enter a valid IP address in the Start IP Address field and a higher IP address in the End IP Address field.

The
start and end addresses define the range of allowable IP addresses from
which users can log in. If you want to allow logins from a single IP
address, enter the same address in both fields. For example, to allow
logins from only 125.12.3.0, enter 125.12.3.0 as both the start and end
addresses.

For example, the following ranges are valid:

0.0.0.0 to 1.255.255.255
132.0.0.0 to 132.255.255.255
132.0.0.0 to 133.255.255.255

However, ranges like 0.0.0.0 to 2.255.255.255 or 132.0.0.0 to 134.0.0.0 are too large.

Normally, queries for a single Visualforce page request may not retrieve more than 50,000 rows. In read-only mode, this limit is relaxed to allow querying up to 1 million rows.

In addition to querying many more rows, the readOnly attribute also increases the maximum number of items in a collection that can be iterated over using components such as <apex:dataTable>, <apex:dataList>, and <apex:repeat>. This limit increased from 1,000 items to 10,000. Here is a simple controller and page demonstrating this:

While Visualforce pages that use read-only mode for the entire page can't use data manipulation language (DML) operations, they can call getter, setter, and action methods which affect form and other user interface elements on the page, make additional read-only queries, and so on.

You can manage exchange rates
between your active and inactive currencies and the corporate currency by
editing the conversion rates. These are static exchange rates that apply to all
currency fields used in your organization. In addition to these conversion
rates, your organization may also use dated exchange rates for opportunities
and opportunity products. For more information about dated exchange rates,
see About Advanced Currency Management.

4.Enter the conversion
rate between each currency and your corporate currency.

5.Click Save.

When you change the
conversion rates, currency amounts are updated using the new rates. Previous
conversion rates are not stored. All conversions within opportunities,
forecasts, and other amounts use the current conversion rate.

If your organization
uses advanced currency management, you can also manage dated exchange rates for
currency fields on opportunities and opportunity products.

When advanced currency management is first enabled, your existing exchange rates automatically become the first set of dated exchange rates. These rates will be valid for all time, until you define another set of exchange rates.

To use multiple currencies, your administrator must specify which currencies are supported for your organization.

Active currencies—These represent countries in which your organization does business. Only active currencies can be entered in opportunities, forecasts, and other items.Once you activate a currency, you can never permanently delete it.

Inactive currencies—These are currencies that your organization no longer uses. You may have existing records that use inactive currencies, but you cannot enter new amounts in inactive currencies.

To activate new currencies:

Click Your Name | Setup | Company Profile | Manage Currencies.

Click New in the Active Currencies related list.

Select a currency. Currencies are alphabetized using their ISO currency code.

Enter the conversion rate relative to your corporate currency.

Specify the number of decimal places to show for amounts in this currency.

Click Save.

To activate a currency from the list of inactive currencies, click Activate next to the currency.

To deactivate a currency, click Deactivate next to the currency. Deactivating a currency does not alter amounts in items that use that currency. However, you can no longer enter new amounts using the inactive currency.

Contact salesforce.com to request Multiple currencies.Be prepared to provide the following information:

The organization ID (production or sandbox)

The default currency stamp for current and future records (USD, EUR, GBP, etc.)

Confirmation that you understand that Multi-Currency can’t be disabled once enabled

Confirmation that you are a system administrator authorized on behalf of your organization to request Multi-Currency enablement and that you consent to the lockout of this organization for a certain period of time, depending on your organization’s data usage volume.

When you want to access the external sites in your Salesforce
application using callouts, webservices, etc... You need to add that in
the Remote Site Settings. This is just a security that force.com platfom
is
going to check.Before any Visualforce page, Apex callout,
or JavaScript code using XmlHttpRequest in an s-control or custom
button can call an external site, that site must be registered in
the Remote Site Settings page, or the call will fail.

For example, you cannot insert an account and then insert a
user or a group member in a single transaction.

Test methods allow for performing mixed DML operations between the
sObjects listed earlier and other sObjects if the code that performs the DML
operations is enclosed within System.runAs
method blocks. This enables you, for example, to create a user with a role and
other sObjects in the same test.

Generally, all Apex
code runs in system mode, and the permissions and record sharing of the
current user are not taken into account. The system method runAs
enables you to write test methods that change either the user contexts
to an existing user or a new user. When running as a user, all of that
user's record sharing is then enforced. You can only use runAs in a test method. The original system context is started again after all runAs test methods complete.

The following items use the permissions granted by the user specified with runAs running as a specific user:

Dynamic Apex

Methods using with sharing or without sharing

Shared records

The original permissions are reset after runAs completes.

The runAs method ignores user license limits. You can create new users with runAs even if your organization has no additional user licenses.