I'm trying to clone a commercial Student Management System which was written in Perl. I want to use PHP, as I have no experience in Perl.
I am now trying to set up the login system, which should be (has to be?) done with PHPSESSID's, right? Now, in PHP I could transmit the Session ID via GET, POST, and COOKIE.
The Perl website doesn't add parameters to the URL (GET) and does not save cookies on my computer (COOKIE). There is also no form which could contain a hidden field (which would be POST in PHP, right?)
Can someone tell me how Perl remembers the logged in user there?
Perl takes a much more "toolkit"-based approach to building web applications than PHP does, because Perl was not designed specifically for web work. So it doesn't have any built-in way of doing web app session management; rather, there are many modules on CPAN which implement session management in many different ways.
If you were to identify the Student Management System in question and provide a URL, we might be able to look at it from the outside and identify what it's doing, but, really, I question whether you actually need to use the same session management system as the existing app unless you want to implement single-sign-on between the original version and your clone[1]. Concentrate on cloning the user-visible interface and functionality rather than the implementation details behind it.
[1] ...which would be futile anyhow unless you're also planning to tap into its session database on the back end, since neither one will recognize the other's session ids if they don't share that data.
For the sake of completeness, there are OTHER, non-standard ways to store/transmit session information than the 3 methods you listed (although I seriously doubt any of them are used in your SMS). Among them:
Sending the cookie data as part of the DOM (e.g. in HTML) and having on-page JavaScript access it from DOM
Or, just store the cookied data as JavaScript's data in the first place.
AJAX calls. E.g. the session-enabled logic is all handled in AJAX URLs and not the main URLs. Yes, I know that's completely screwy. But doable.
Don't store the cookie in main cookie database (so you can't find it using standard cookie viewing methods). For details on how that's done, please google "evercookie" for a VERY cool method of persistently storing cookie info by utilizing up to 10 redundant storage options - one good intro is http://blog.depthsecurity.com/2010/09/super-persistent-cookies-evercookie.html
All that said, I completely agree with Dave's answer - just use PHP's best practices mechanism to implement the functionality instead of cloning possibly-perl-specific and possibly-weird implementation in the webapp.
Related
I am new to Squarespace and I was wondering if it can interact with an external Rest-API using JSON?
For example, say I have a Database being hosted privately and I want data from it to be shown via Squarespace and certain pages being restricted according to the user's privileges.
Is any of the above possible, and if so can you direct me to an example? I seem not to be able to find anything on the above via google.
Thanks
From Squarespace:
Squarespace doesn’t support server-side code, including PHP, Ruby, Ruby on Rails, and SQL.
Therefore, the only way to connect to an external API (besides those supported by Squarespace's official 'extensions') is to use "client-side" (in-browser) JavaScript.
So, the database solution which you use must be capable of securely handling client-side connections (for example, Firebase can do that). To interface with it, you must add the JavaScript to your Squarespace site via code block or code injection. An example explanation of doing that can be found at this question.
As to allowing/disallowing content based on data returned from the database, it can be done, but only client-side. That means that, while you can make the site appear to restrict access and/or make it inconvenient for others to access certain pages based on information in the database, because it is all client-side, it could technically be circumvented by someone if they are familiar with web-development, web-inspector, etc. So it's not something you'd want to do if it is critical that the content be truly restricted.
Squarespace does have its own "Members Areas" which can be used to solve content access problems. However, it's extremely limited at the moment, and there are many scenarios it does not address.
Preface
Normally, a session in a web application stores data for a specific user (and its data is available across any visit of the user to the same web server/site).
Embperl (a templated web development framework in Perl) has a very interesting feature: user-independent session data stored/retrieved at the level of individual web page (%mdat hash).
QUESTION:
Does a similar feature (user-independent "session" data accessible to all users' requests) exist in any other web development environments/stacks, either in precisely the same form (perl web page data) or somewhat similar?
I am specifically asking about a feature implemented/accessible as part of a web framework, not the obvious and easily done DIY solution of "well you can easily implement your own via a $backend_database_store with a key of the page URL" .
This is a purely theoretical question borne of my trying to find non-Embperl analogue to help explain Embperl's %mdat feature. I don't care which web development stack/framework the example is from, as long as it's not something totally obscure used by 3 people in the universe :)
Background:
This came about from trying to answer a recent Embperl question about %mdat hash; I tried to explain it by comparing it to some other feature in web development. I then realized that I don't actually KNOW any other framework with a similar feature. buit I'm sure on MUST exist :)
Yes, although it called "cache".
e.g. in Mason $m->cache will return your whatever object. even a %mdat if you like to.
http://www.masonhq.com/docs/manual/Devel.html#data_caching
Your "user-idependet session data", smells like cache, looks like a cache and reads like cache. Only missing some features - e.g. you can use $m->cache at every level of your application.
I've been asked to create an app that will get data back from a database where the CMS will be Wordpress. I've never used a CMS so I'm trying to get a (overview)picture in my head of how it could all work and what each of the components would be. And what a CMS actually brings to the party.
Creating the app itself is pretty clear. I've done a few already. I've made a database before and shouldnt cause a problem.
But what is going to be in the middle between the app and the database?
Part A:
I'm guessing iphone apps typically would call some php file that's hosted on the server? The php then would make a call to the database and return the data somehow, maybe as xml. But this is really basic and wouldnt require a CMS. Just a database and a phpfile, or am I wrong?
Part B:
If i wanted to run a check on the database every minute to see if any of the data in database was no longer valid and remove it if needed, that would require somekind of program running on the server. So that program would be Wordpress, since it is managing the content, so a content management system is actually needed and is for these kind of taskes. Am i understanding the role of CMS?
Many Thanks,
-Code
Part A: Yes, that's definitely how it would normally work. Of course, you're not accessing "a" database, you're accessing the database WordPress creates, but otherwise, sure.
Part B: The role of a CMS is to provide a structured, easily-edited way of presenting information. It abstracts both the database and the user interface stuff, allowing the CMS administrator to CRUD data via the use of simple forms.
In your case, no, you wouldn't (usually) ask the WordPress software to provide information because it's not set up to provide data that's programmatically requested. Instead it's designed to display HTML pages with the data embedded. The WordPress software is specifically for humans to CRUD the data through a human-friendly interface. You'd write your own, as in Part A.
This article shows some basic PHP for retrieving blog entries and user comments, likely most of what you'd want. The WordPress database format is well-documented: here's an article that lays it out and provides more PHP examples for retrieving the information.
Have a look how the Wordpress for iOS team is doing it:
http://ios.wordpress.org/development/
I would not try to access the db directly or through some custom php-code, but use the official WordPress API (which uses xml-rpc) instead.
and this xml-rpc objective-c library might even make this a pretty straightforward exercise?
I'm trying to make a page with 2 fields (email and feedback) and 1 button. When the user clicks on the button, a table on a page else where is filled in with the data, permanently.
Does anyone have recommendations of how I should do this? I'd like to avoid having a script send me an email, or writing to a database. But if I have to, which ever is easier to configure would be prefered.
Thanks,
Matt
So you want a comments system like you find on most blogs? You'll need to store those comments somewhere, probably in a database. As for how to do it, that would depend entirely on what you already know and what the site is currently written in. You could use PHP and MySql if you already have those skills, or ASP.Net/SQL Server, or if you want to be down with the cool kids you can use Ruby on Rails or Python/Django.
If you post what languages you already have experience in, and/or what the site is written in you might get a more specific answer :-)
There're 2 types of scripts: server side and client side. The client side script (JavaScript) stores info only for particular visitor on his computer and this can't be seen by anybody else.
You need a server side script to save feedback on the server. The language or technology depends on the hosting server you use. Not all hosting services allows server side scripts. You need first to find out what scripting languages and technologies are supported by your hosting provider. Then we can help you more.
ADD:
For an unexperienced persons I recommend to search for hosting services which has most needed functionality. Something like blogs, etc. On such services you could create pages that will have comments and feedback and many more.
While it may seem outdated it's not necessarily a bad design. You can use PHP or Perl (due to it's string parsing capabilities) and simply store the main page on the disk.
Here's your sudo code/design...
You'll need need an html page that looks as follows
<tr><td>email</td><td>comment 1</td></tr>
<tr><td>email 2</td><td>comment 2</td></tr>
<tr><td>email 3</td><td>comment 3</td></tr>
Then you'll need a php script page that will read this html file in and display it.
The php page will also contain code for dealing with a user submitted comment. When a user posts a comment you need to open the html page with the rows in it and append to that file.
You need to be careful with this design however because you may run into write concurrency issues if two people attempt to read the file at the same time. Add code to handle this gracefully accordingly.
I want to maintain state in my Perl web app. How can I do this effectively? I looked at CGI::Session but it says that it doesn't work well with UTF-8 pages, which is a requirement. I'd also like to be able to pass some basic information to another Java application running on the Glassfish app server, so people aren't forced to login to both apps, for example. How can all this be managed?
The basics of sessions are that you need a place to hold the session data (the store) and a way to store and retrieve the session data. While some frameworks call that The State, it really boils down to having a session key (or session ID) and passing it back to your app via either a cookie or a URL parameter.
Your store can be anything that can hold the data for you. Some examples are: a flat file, a dbm file, a DBMS,or an in-memory cache of some type.
The most common implementation, which is used by CGI::session and Apache::Session is to have three fields in each record inside the store: session_id,session_data, expires_time.
The session modules on the CPAN take care of loading your session at the beginning of the request, and storing it back at the end.
The bug referenced in the documentation for CGI::Session is marked as "resolved". That one was about utf-8 in the database.
It seems that you still should not use 'use encoding utf-8'. But why would you do that in the first place? "perldoc encoding" says "allows you to write your script in non-ascii or non-utf8". WTF?
Having your resulting HTML utf8-encoded does not seem to be an issue when using CGI::Session.
Find a Perl web framework that handles sessions for you.
For example Catalyst. It will completely abstract out user sessions so that you don't really even have to think about it. See a tutorial on how to use sessions with catalyst.
If you're programming a website in Perl, you should really be using this framework anyways.
Hm, if it is not too late.
CGI::Session works just fine with any data. It depends on the serialization format that you use for your session and how you store them in your database.
I would suggest also a combination with CGI::Simple for which I added UTF-8 form-data handling.
Is your connection to the database UTF-8 enabled?
for MySQL you can use:
SET NAMES UTF8;
as the very first statement after connecting;
Do you store store your session in a text field with some different encoding?
Just take a little care with such things and you will be fine.
You can look at some examples of usage here.
Your best bet would be to generate some sort of session key and store it in a cookie on the browser. Then, use that key to store information in either a database or memcached that both can access.