With Flex 3 comes the ability to do runtime localization. Compared to Flex 2 where you actually had to recompile your application for each locale, you can now have one version of your application that contains different resource bundles.

Today I implemented this in one of the applications we are working on and ran into some issues. Here is how I got it to work in a nutshell. (Note: for a full instruction on implementing localization in Flex 3, I recommend the article Flex 3:Feature Introductions: Runtime Localization by Gordon Smith.)

- create a folder in your project to store your resource bundles (e.g. “locale”)
- create a subfolder for each locale you want to implement (e.g. “locale\nl_BE” and “locale\fr_BE”)
- in the locale subfolder, create a resources.properties file and save it as UTF-8
- enter the resources in the form of “key=value”, like Ant property files
- update the compiler settings: -locale=nl_BE,fr_BE -source-path=locale/{locale}

You now also need to create localized framework resources. To do this, take the following steps:

- open a command line (run as administrator in Vista!)
- go to the “bin” folder in your Flex SDK installation folder
- run the copylocale.exe tool for each locale, this will copy the localized framework files from one locale to another (copylocale en_US nl_BE)
- check FLEX_HOME\frameworks\locale to see if the folder for your new locale has been created
- if you get an error “could not find resource bundle charts”, search for a file called charts_rb.swc and copy it to the new locale folder in FLEX_HOME\frameworks\locale

A simple example of asking for a localized string:

PLAIN TEXT

Actionscript:

1. // tell the compiler what resourcebundle to use

2. <mx:Metadata>

3. [ResourceBundle("resources")]

4. </mx:Metadata>

6. // if you are in a subclass of UIComponent

7. var myString:String = resourceManager.getString(“resources”, “myKey”);

9. // …or if you are not in a subclass of UIComponent

10. var myString:String = ResourceManager.getInstance().getString(“resources”, “myKey”);

You can put these calls in a binding expression and switch your locale at runtime by setting the localeChain property on the resourceManager:

PLAIN TEXT

Actionscript:

1. resourceManager.localeChain = ["nl_BE"];

That’s about it. Have fun!

March 22, 2008 by shemesh

Beats me why this is not implemented into Flex, it seems to me like a very basic/natural/user-friendly behavior that any date chooser should have.
I m talking about the ability to drag-select a range on the DateChooser.
That is: mouse down, drag to select a range of days, mouse up.

This component extends DateChooser to add a new property: dragSelect (true/false).
Notice that (obviously) ‘allowMultipleSelection’ must be set to true in order to use the drag-select feature.

Also in this demo you can see a custom date range validator with minimum and maximum allowed days.

Demo is here (right click for source)
Source is here

Persistent login cookies are the cookies that are stored with your browser when you click the “remember me” button on the login form. I would like to be able to say that such cookies are obselete, and we have a better way of handling user logins, but they aren’t, and we don’t.

The following recipe for persistent cookies requires no crypto more powerful than a good random number generator.

Premises

1. Cookies are vulnerable. Between common browser cookie-theft vulnerabilities and cross-site scripting attacks, we must accept that cookies are not safe
2. Persistent login cookies are on their own sufficient authentication to access a website. They are the equivalent of both a valid username and password rolled into one
3. Users reuse passwords. Hence, any login cookie from which you can recover the user’s password holds significantly more potential for harm than one from which you can not
4. Binding persistent cookies to a particular IP address makes them not particularly persistent in many common cases
5. A user may wish to have persistent cookies on multiple web browsers on different machines simultaneously

Charles’ Recipe

The cookie should consist of the user’s username, followed by a separator character, followed by some large random number (128 bits seems mind-bogglingly large enough to be acceptable). The server keeps a table of number->username associations, which is looked up to verify the validity of the cookie. If the cookie supplies a random number and username that are mapped to each other in the table, the login is accepted.

At any time, a username may be mapped to several such numbers. Also, while incredibly unlikely, it does not matter if two usernames are mapped to the same random number.

A persistent cookie is good for a single login. When authentication is confirmed, the random number used to log in is invalidated and a brand new cookie assigned. Standard session-management handles the credentials for the life of the session, so the newly assigned cookie will not be checked until the next session (at which point it, too, will be invalidated after use).

The server need not make the effort of deliberately trying to avoid re-assigning random numbers that have been used before: the chance of it happening is so low that even if it did, nobody would know to make use of it.

When a user logs out through some deliberate logout function, their current cookie number is also invalidated. The user also has an option somewhere to clear all persistent logins being remembered by the system, just in case.

Periodically, the database is purged of associations older than a certain time-period (three months, perhaps: the size of the table would be far more an issue than any possibilities of collision in a 128 bit random space).

The following user functions must not be reachable through a cookie-based login, but only through the typing of a valid password:

• Changing the user’s password
• Changing the user’s email address (especially if email-based password recovery is used)
• Any access to the user’s address, payment details or financial information
• Any ability to make a purchase

Results

If the login cookie is compromised, the attacker has access to the common functions of the site as that user. This is inevitable whatever the cookie contains. However, the attacker can not:

• Access sensitive user information
• Spend the user’s money
• Recover the user’s password and try it on other sites
• Prevent the user from receiving notifications from the site of things that may have been done in their name
• Share the stolen login with others

The mutating nature of the cookie also provides a much smaller window of opportunity for an attacker to exploit a stolen cookie, and means the attacker must be far more careful they don’t end up with a useless set of credentials.

Update: Barry Jaspan suggests an addition to the protocol that would further reduce the window of opportunity for stolen cookies: if a cookie that has been known to be used before (and thus invalidated) is presented, treat it as evidence of an attack and invalidate all saved logins for that user.

only for the yum command. If you do not have an internet connection you can download this rpm on another machine from
http://livna-dl.reloumirrors.net/fedora/
just choose your fedora-release number being 8 then choose your architecture. You will need to choose the ndiswrapper version number that matches your kernel version number

Code:

uname -r

from your linux box.
EDIT: then to install it you will need to use rpm instead of yum.

Code:

su
rpm -ivh /path/to/rpm/*ndiswrapper*rpm

___________________________
The answer to all of lifes questions are buried somewhere in the Google search engine.

Code:

[Stephen@localhost ~]$ whatis this?
this?: nothing appropriate

 

 

 

Code:

su
rpm -ivh http://rpm.livna.org/livna-release-8.rpm
yum install ndiswrapper

Sorry I forgot that ndiswrapper was not in the standard fedora repository.
___________________________
The answer to all of lifes questions are buried somewhere in the Google search engine.
Code:

[Stephen@localhost ~]$ whatis this?
this?: nothing appropriate

http://www.gidforums.com/t-4390.html

ndiswrapper -i /mnt/cdrom/Driver/bcmwl5.inf

ndiswrapper -l

Installed ndis drivers:
bcmwl5  driver present, hardware present

modprobe ndiswrapper

dhcpcd wlan0

Finally, we want to make sure that this is loaded every time at boot up. There is quite a few ways to do this, but what it boils down to is that you need to load the ndiswrapper driver and then configure the card. Under slackware, I chose to use the rc.local script. This is the last script to run on boot up. I added these lines to my /etc/rc.d/rc.local script:

Code:

echo "Set up wireless lan"
modprobe ndiswrapper
dhcpcd wlan0

http://livedocs.adobe.com/flex/3/html/index.html