News:

The anti-spam plugins have stopped being effective. Registration is back to requiring approval. After registering, you must ALSO email me with your username, so that I can manually approve your account.

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - yny-u

#1
Great, thank you very much. All working now ^^
#2
Yep, the problem goes away if I use the skip scriptaculous version.. But the banner doesn't display. I guess that is why my quick anddirty attempt at a fix didn't work (I tried changing all instances of "overlay" in the lightbox code to "lb_overlay", but that did not fix the problem.

Here is a link to a test version of my top page with the banner reactivated. You will see why I disabled it ^^;

http://yny-u.com/test/

Thank you for your help.

*edit*
I am using Firefox v. 3.6.3 on a Mac, haven't had a chance to test and see if the same thing occurs in IE..
*/edit*
#3
It looks like both the Xepher link banner and Lightbox 2 (a Javascript based image display thing) use an element (a div, I think) with the "overlay" id, and this messes Lightbox 2 up.. Would it be easy to change the Xepher banner's id to "xepher_banner_overlay" or something? Might be good to change it to more specific id for something that is included on so many pages anyway.

I have tried fixing this by changing the Lightbox 2 id, but it turns out that this is rather more involved than I can manage at the moment.

~Thanks
#4
Web Design / Re: Cleaning up PHP $_GET URLs
May 18, 2009, 10:37:59 PM
Heheh, well it certainly is easy to get 500 errors when messing about the your .htaccess file... But having a lot of rules does not inherently generate an error. As long as all your rules are correct and don't conflict with each other there should be no problem (obviously).

Anyway, if you structure your URLs in such a way that each piece of data can be distinguished by some sort of regexp, you can probably set it up so that the order of the URL doesn't matter, ex. http://milenium.senshuu.com/mil/1/1235775579/showcomments/ and http://milenium.senshuu.com/1235775579/showcomments/mil/1 could both be fine... It makes writing your rewrite rules a little more complicated, but it should be doable. Is that what you mean by not being relative to a certain subdirectory? Or you can choose to only rewrite certain pieces of data and just pass everything else, ex. http://millennium.senshuu.com/mil/1/1235775579/?subaction=showcomments&start_from=1234

Does that help? Sorry, I am not quite sure what your question was..
#5
Hahah, yes. I was tempted to mention the unplug/power-down/smash security option.

But seriously.
The point I was trying to make is that if you expose *more* than just the user id, you need to be careful.

And anyway, no matter how random your cookie is, someone can always just hijack the session or something, so any small boost in security (if any) you might get from using sessions doesn't really help much... Which is what you are saying, correct?

Thanks again.
#6
*Edit* I am mostly talking about what might happen if for some reason you decided to store more than just a user ID in the cookie, which is not really what Databits is talking about doing above. Just a clarification. *Edit*

Especially useful for semi-public authenticated applications (forums and such) where you are dealing with a lot of users, and the damage from somebody breaking into the system would be comparatively small, or if you aren't actually storing really sensitive stuff in the cookie. You can be clever about what how you use user data, and which data you store... For example, a credit card number might not need to be stored efficiently.. You might only have to check it once.

I guess this, like most other security questions, boils down to a trade-off between security and usability/efficiency.

If you are dealing with very sensitive information–say credit card or bank numbers–this might not be such a good idea. Unix systems used to store passwords in a similar way (in a public file, but hashed–back before they started using the shadow file), but one of my teachers recently had us crack a bunch as homework. Somebody will at some point crack MD5, especially as there is probably a lot of money to be made in doing so (legitimately or otherwise). Of course no system is really secure, but at least if you are only storing a random token in the cookie, you are not exposing any data in semi-public fashion (even if it is encrypted). Obviously, if someone breaks into your database they can still get the data, but as long as you are only storing hashes in your database, at least two major things (rather than just your encryption) need to fail before any real data is exposed.

Anyway, I just thought I should emphasize that all solutions are ultimately a trade-off, and you need to decide on a case-by-case basis.

Thanks for the tip Databits. Any way of avoiding disk I/O is good ^^
#7
Announcements / Re: Welcome to the Dog Star
May 04, 2009, 03:35:51 PM
Thanks for the help tapewolf.

On a side note, Mac OSX users can show/hide hidden files by entering the following two shell commands:


defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder


To have the system hide the files again, simply re-enter the commands with FALSE instead of TRUE.

(Or, you can go get a Dashboard widget to put a nice user interface on the process.. http://www.apple.com/downloads/dashboard/developer/showhidewidget.html )
#8
Web Design / Re: Cleaning up PHP $_GET URLs
March 05, 2009, 08:09:02 PM
This can get complicated, but you probably could get something like:

http://milenium.senshuu.com/mil/1/1235775579/showcomments/
With:
RewriteRule ^mil/([0-9]+)/([0-9]+)/([0-9a-zA-Z)(/)?$ mil/index.php?ucat=$1&id=$2&subaction=$3

(That is just off the top of my head, so it probably has some mistakes...)

The $# things in the second half of the RewriteRule (after the first "$") refer to the thing matched by the regular expression subsection in the #th set of parenthesis counting from left to right. You can add more variables (like your start_from and archive variables) quite easily. The trick is to remain consistent about what order you put the variables in, otherwise you will end up with ucat getting id's value or the like.

Hope that helps.

#9
Web Design / Re: CMSeseseses..
March 03, 2009, 03:12:31 PM
I was looking at doing something similar a while back, but ended up just building the whole thing myself, as that seemed easier than getting someone else's code to do what I wanted..

That said, you might want to take a quick look at http://codex.gallery2.org/Main_Page

@Senshuu if you don't like ugly URLs, ModRewrite is your friend: http://xepher.net/forum/index.php?topic=645.0
#10
Web Design / Re: General CSS Thread
March 03, 2009, 03:11:28 PM
Test in multiple browsers.. Always test in multiple browsers.

Yahoo has a library of CSS styles that goes some way to neutralizing these cross-browser issues. It has a few quirks, but it can save a lot of trouble.. http://developer.yahoo.com/yui/reset/

Hope that helps.
#11
Web Design / Re: Wonderful Style-Switching!
October 05, 2008, 09:48:22 PM
Actually this sort of thing can be really handy under the surface for getting around browser specific issues *coughIEcough* or making platform specific layouts (for iPhone and the like)...
#12
Applications / Re: Got the Point? by Raiettei
October 02, 2008, 08:38:43 PM
Do you have any experience building websites? You will need to build everything yourself here, so you at least need to know HTML and how to upload files to a web server.

Can you provide an example of what you can do web design wise?
#13
Applications / Re: KTK - application
September 03, 2008, 03:25:59 PM
Looks pretty good to me..

You might want to make so that users can open up gallery images in a new tab/window manually, rather than forcing a popup. I like being able to open up multiple images in new tabs when looking through galleries, so I find it rather irritating when I open those tabs to find a bunch more gallery index pages.

At least add a little check to your Javascript that makes sure that the user's browser supports Javascript and has it enabled.

If you need advice on doing either of these things, I would be happy to help.
#14
Applications / Re: Jinxville
February 19, 2008, 10:36:31 PM
Welcome aboard ^^
#15
Applications / Re: Celebrate films
February 15, 2008, 08:20:03 PM
While the <center> tag still works in most browsers, it was deprecated as of HTML 4.01 or something (http://www.w3schools.com/tags/tag_center.asp), so you might want to stay away from it.. You can centre layouts using CSS, though as tickyhead mentioned, this can be a bit complicated..

http://jigsaw.w3.org/css-validator/ is a very good web page validator that will check for things like deprecated tags, improperly closed tags, duplicate tags, etc., and give informative error messages about what error occurred where, and often suggest how to fix it. Here is a link to the page I get when I run your test site through the validator: http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fcelebratefilmstoo.bravehost.com%2Findex.html&warning=1&profile=css21&usermedium=all
Hope that helps.